Getting the Database to Scale

The real limitation governing the scalability of most read-heavy sites is the number of available database handles. Scaling up the application server layer does not make sense if the database can only deal with a limited number of read/write handles. Some high-end Oracle cluster solutions may possibly help solve this problem, but MySQL clusters cannot be used since they do not support sub-queries. Standard master/slave configurations are therefore the only option. As far as CCI Europe is aware, all current Content Store sites are based on master/slave database configurations, regardless of what database they use.

You are recommended to install memcached on each of your engine-hosts. memcached acts as a layer on top of the most important Content Store cache, /neo/xredsys/presentation/cache/PresentationArticleCache, and significantly reduces the number of database read operations. See Distributed Memory Cache for details of how to install memcached on your engine-hosts.

The relationship between memcached and in-memory caches

The Content Store uses memcached as a "level 2" cache for the presentation layer. When the templates ask the presentation layer for an article, it first checks its in-memory cache - even if memcached is in use. If the object isn't found in the in-memory cache, then memcached is asked. If the object isn't available there either, then the object is loaded from the database and copied to the in-memory and memcached caches. When memcached is in use, some cache-related activities affect both the in-memory and memcached caches, while other activities affect only the in-memory cache. For example, functional activities such as adding and removing a specific item from a cache are propagated to memcached, whereas operational activities such as flushing the cache or setting the cache size, are not propagated to memcached.