Sí, el XCache debe estar sólo accesible por CVS.

En 2bits tienen un montón de artículos dedicados al tema.

Ahh, la semana que viene tendremos un nuevo server aunque todavía no hemos decidido cual pero será mejor que el que tenemos eso seguro.

En mi experiencia, el cuello de botella de Drupal (sobre todo si usas views, CCK y todas esas interfaces tan chulas) es la base de datos. Y para aliviar la base de datos, guardar caché en base de datos no ayuda. Así que me decanto por soluciones como boost. Si la web tiene un porcentaje significativo de usuarios anónimos, una caché en HTML como la que proporciona boost puede reducir la carga drásticamente.

Por otra parte, en Drupal hay una capa de base de datos muy potente que con no muchas modificaciones (aunque, eso sí, bien pensadas :)) permite implementar MySQL master/slave. De esta forma, se pueden tener varias máquinas respondiendo a la base de datos. De momento no hay un módulo que proporcione esto (tengo entendido que se está viendo para Drupal 7-8) pero cualquier organización o empresa que use Drupal a cierto nivel llegará pronto a problemas como este.

No quiero hablar mucho de este proyecto en concreto porque aún estamos definiendo qué se puede contar y qué se puede liberar. Espero poder tener pronto claro qué se puede contar y contarlo de la mejor forma posible. Mientras, te invito a crearte una cuenta y medir los tiempos. Descubrirás que hay muy poca diferencia de velocidad entre usuarios anónimos y usuarios registrados.

Con memcache no tengo ninguna experiencia. Hemos optado por replicación master-slave y un buen pool de slaves. Las operaciones de escritura lógicamente van al master, pero la carga que soporta es mínima. Lo bueno de master-slave es que es casi totalmente transparente al software (está prácticamente centrado en la capa de abstracción de base de datos) y no es una caché, sino que realmente se construye la página de la base de datos.