Almacenamiento en caché de la rutina de arranque Drupal

Tengo curiosidad por saber si alguien ha intentado "almacenar en caché" el proceso de arranque en Drupal.

Normalmente, Drupal ejecutará las 7 fases de arranque en cada solicitud, pero tal vez en un sistema de producción implementado, ¿uno podría "eliminar" algunos o todos estos?

Las posibles sugerencias que tengo en mente podrían ser

1. Serializar el estado de arranque y pegarlo en la memoria caché
2. Un script podría generar un parche para bootstrap.inc que codificará cierta información en el archivo.
3. Creo que David Strauss ha tratado de mantener a un Drupal arrancado con libertad.
4. Otra locura?

¿Qué intentos hay y cuáles se sabe que son (algo) confiables?

PHP es una arquitectura de nada compartido. Eso tiene sus ventajas y desventajas.

Una desventaja es que no es fácil hacer algo como esto. No hay mucho estado que pueda almacenarse en algún lugar.

Hice algunas pruebas rápidas y cuando inicié sesión, el boostrap parece tomar aproximadamente ~ 17% del tiempo total y más del 50% de eso realmente está cargando todos los archivos .module e .inc. Eso no es algo que pueda almacenar en Memcache. Además, no parece importar mucho si uso memcache o el caché de la base de datos.

Intenté obtener algunos resultados cuando habilité el caché de página, pero Xhprof no parece devolver resultados confiables en ese momento; Todo parece ser demasiado rápido. Pero incluso entonces, la mayor parte consiste en ejecutar ganchos de inicio / salida y cargar archivos que parece. Encontré un problema interesante allí: parece que el módulo de usuario está ralentizando seriamente la respuesta de la página en caché porque activa el registro debido al controlador de entidad en el archivo .module.

Dicho esto, David Strauss mostró un trabajo experimental en Copenhague, donde creó una instantánea de memoria después del arranque y luego regresó a eso una vez que se sirvió la página. Él usó Drupal 6 para eso. Después de mirar los números anteriores, imagino que las ganancias de rendimiento de hacer esto en Drupal 7 serían bastante menores. Una razón para esto es que la conexión de la base de datos está cargada de manera diferida (y puede llegar bastante lejos cuando se usa, por ejemplo, Memcache antes de que necesite ejecutar la primera consulta) y hay mucho que se almacena en caché.

Lo que es realmente malo en Drupal 7 es la capa de renderizado con estas enormes matrices e infinitas recursiones y bucles. Ese prácticamente deshace todo el trabajo de rendimiento que entró en Drupal 7. Veamos cómo se ve en Drupal 8, si Twig lo convierte en núcleo.

Por último, sobre las ventajas mencionadas. Una gran ventaja es que los puerros de memoria son bastante irrelevantes porque todo se libera después de cada solicitud. He visto muchas aplicaciones Java donde el uso de memoria aumenta constantemente y necesitan reinicios regulares.

No, fue David Strauss quien estaba experimentando con el evento kargo (ahora llamado Kellner) en https://code.launchpad.net/~fourkitchens/pressflow/6-evented pero dudo que algo serio salga de eso.

Drupal 7 ya tiene un montón de bootstrap almacenado en caché, hay un cache_bootstrapcontenedor para eso. Puedes pegarlo en memcached.

Puede ir por la borda y disminuir la carga del código moviendo algunos / muchos códigos Drupal a C. Damien y dhthwy creó la extensión PHP en http://drupal.org/project/drupal_php_ext, no se hace mucho con ella. O hacer hiphop. No sé el estado actual de hiphop y Drupal 7.

Al final del día, sin embargo, debe analizar detenidamente los costos de ingeniería de, por ejemplo, obtener trabajo hiphop con Drupal 7 (¡y todos los aportes!) Y compararlo con alquilar algunos servidores más. Si puede ahorrar, diga el 5% de sus servidores y tiene 100 000 servidores, hágalo, pero ¿es usted Facebook? Sea cuidadoso y económico con las optimizaciones.

Vi una presentación interesante sobre doh (Dynamic Object Handler) en la reunión de alto rendimiento de Drupal . En resumen, habla sobre bootstrapping drupal rápido al usarlo. Se pone interesante alrededor de las 15:30. Carga automática de esteroides en resumen con runkit funcionalmente también. Control de calidad a las 33:00.