Getting the Database to Scale

The real limitations of (mostly) read sites are the DB handles, as scaling the application server layer does not make sense when there is just "this many" read/write handles the database can handle. It might be that the higher end Oracle cluster solutions have something to offer here, but at least the MySQL cluster is not an option (it does not support sub queries), so you are stuck with a normal master/slave solution and this is what we believe all our current ECE sites are running with, regardless of the DB vendor.

It is important to remember that both the read and write connection pools in ECE must be configured to work on the master DB instance.

The slave DB(s) are only for data redundancy (standby backup) and should not be used to serve requests as this may cause unforeseen behaviour.

To ease the strain on the database, installing memcached on each ECE host is recommended. Memcached will act as a layer on top of the /neo/xredsys/presentation/cache/PresentationArticleCache, the most important ECE cache (called ArticlePresentationCache in ECE <= 5.1), and will reduce the database read operations significantly. Please see the "Escenic Content Engine Admin Guide" for details on how to install the memcached ECE integration.