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.