LiveSite Runtime Architectures for large, high-volume, multi-site implementations
I'd like to poll this group for ideas, thoughts and input around Architecture Best Practices for implementing LiveSite Runtime for large, high-volume, multi-site implementations, and the corresponding performance and scalability considerations associated with such architectures. The "classic" customer scenario for such an implementation 'typically' involves the following requirements :
1. Multi-site implementation - many websites, for many languages/locales, for many brands/products/subsidiaries - lot of localization.
2. Large content volumes - Significant amount of content (DCRs) and associated assets (graphics/images/videos) in TeamSite, organized at the global level and at the local level per site
3. Frequent/bulk updates and content publishing operations from TeamSite to LiveSite Runtime
Based on my limited understanding of the LiveSite Runtime product architecture, I can see the following "challenges" that would potentially need to be dealt with in such a scenario :
1. Single set of LiveSite Runtime instances for all websites (across all brands/products/languages), or a "distributed" LiveSite Runtime physical/logical architecture with a method of segregating the runtime instances / clusters of runtime instances, by "groups" of site - basically, how much can a single set of LiveSite Runtime instances scale up to ?
2. Content Publishing and Deployment of DCRs and corresponding assets to the same LiveSite runtime instance - Since each site has its own DCRs and its own content (and agreeably which some of it is shared), bulk of it is localized, what are the implications of publishing millions of DCRs and assets to the same set of LiveSite Runtime instances, for all sites ? In TeamSite, all of this is beautifully organized in branches, but in LS Runtime, all of this sits under a big file/folder structure under "sites". How would you efficiently manage that ?
3. Caching within LiveSite - Can the in-memory vs. disk caching model supported by Apache JCS (which is what LiveSite uses), scale up to handling thousands of components and pages, with different component variations and references (based on URL parameters, etc.), and handle that efficiently ? What does it mean to cache population and cache management ? What does it mean to cache invalidation and cache flushing, post a publishing operation ?
There may be other things as well.
We're trying to evaluate the architecture for a current platform, and potentially making the case for a "Distributed" LiveSite Runtime Cluster (architecture model), where we would segregate the Runtime Clusters in different groups, by groups of sites, or brands, or some other model. We're hopeful that with such an approach, the individual groups of LS Runtimes may be more scalable as opposed to a single set managing every single one of these sites ?
I want to validate if someone else in the community has done something like this, or has any input to offer around LiveSite Scalability in the context of such a scenario and the considerations above.
An help/input would be most appreciated.
