Page History

...

...

• Janitor is deactivated on the public instances (see 132581478 Clustering below). Hence the Journal could reach a critical size. One way to solve this issue is to recreate a new fresh cluster regularly.
• On BlueMix, a single DEA has fairly limited CPU resources. This is not really an issue for the public instances, since they can scale horizontally (adding an instance to the cluster). However, it does limit the author instance where scaling is not feasible.

...

• Using several sets of clusters reduces the risk at the database-level. The Cloud Foundry router must be configured to route dynamically to one of the clusters in the set. Adding a new cluster is straigtforward in Cloud Foundry. However, activation from the author instance to the public instances does take more time. Recreating a new cluster also takes some time since the database must be copied and the Lucene indexes fully recreated. The Synchronization module can also be used in this context.
• Clustering the database itself. Usually called master/slave, or replication. It is not a SQL standard and thus is specific to each database provider. This approach looks interesting at a first glance since it is totally abstracted from the application and performance is typically better. However, the configuration could be complex and rely heavily on the available tools.
• Using a shared cache: A shared cache can be used to cache pages and assets, and reduce the number of requests on public instances (for static content). Public instances are configured not to cache this content. Usually, Cloud Foundry platforms provide a global cache out-of the box that can be set up with one click. However, an efficient cache invalidation requires a deeper integration in Magnolia.
• Using a global HTTP session cache: Cloud Foundry platforms ususally provide this mechanism out-of the box. Sticky sessions are also supported, but do not help in this specific case, because they limit the scalability of the cluster.