EDITAR: leí mal la publicación original. 168 módulos es mucho, y 300 a 700 ms de consultas SQL es enorme . Cuantos más módulos use, más consultas serán tan pronto como los módulos realicen algunas.
Use el almacenamiento en caché agresivo mientras pueda, guarde en caché todo, si no es suficiente, intente con un caché de proxy inverso. Usar un CDN para archivos puede mejorar enormemente todo el asunto. Un caché de proxy inverso también puede ayudarlo al eliminar algunas cookies de autenticación al acceder a páginas que no lo necesitan (entonces el núcleo pensará que el usuario es anónimo para ellos y maximizará el almacenamiento en caché).
El dinamismo central de Drupal hace que todo el amanecer sea lento tan pronto como tenga demasiados módulos interactuando al mismo tiempo.
Yo diría, por ejemplo, si usa muchos módulos que cargan datos en el tiempo hook_node_load () en lugar de usar campos, hará muchas consultas mientras que el uso del campo garantizaría la eficiencia del almacenamiento en caché.
La representación también puede llevar mucho tiempo, drupal_render () (la API de representación que se llama en algún momento) es una buena pieza de API (realmente útil) pero también un poco lenta. Cambiar a PDO (D7) y el DBTNG completo (que es genial por cierto) también agrega latencia no despreciable.
Dicho esto, el núcleo en sí mismo es bastante rápido (pero hace demasiadas consultas SQL, incluso con casi nada instalado), los módulos mal codificados a menudo son el cuello de botella.
APC puede dividir el tiempo de ejecución por 2 o 3, según el código que se ejecute. si lo configura bien (habilite todas las optimizaciones de APC, el manual oficial de APC está bien escrito y lo guiará).
Si está en una caja con un sistema de archivos lento (sistema de archivos de red o disco duro lento) puede implicar un impacto visible en el tiempo de ejecución. Drupal está hecho de mucho archivos pequeños, lo que obliga a PHP a hacer E / S en el FS cada vez que carga uno de ellos (APC también ayuda mucho para eso).
Un DBMS mal configurado también puede ser un cuello de botella bastante feo, si está utilizando MySQL piense en hacer un ajuste fino. Si está en un alojamiento compartido, si no es específico de Drupal (o está listo), la pila DBMS y PHP probablemente esté mal configurada o no esté ajustada, lo que puede conducir a sitios realmente lentos.
No olvides activar todos los cachés. Si su sitio no está autenticado orientado al usuario, active el almacenamiento en caché agresivo de la página (es realmente sorprendente).
Cuantos más bloques tenga, más páginas completas serán lentas, los bloques del módulo de Vistas serán un cuello de botella al amanecer (dependiendo de los complementos de Vistas que use, el bloqueo de OG puede ser un verdadero dolor) si no restringe su visibilidad por página, o con código PHP personalizado (cualquier otro bloque también, siempre configure la visibilidad de su bloque manualmente, ayuda mucho al marco evitando que intente representar bloques vacíos).
Evite los módulos que usan hook_init (), hook_init () se está ejecutando en cada página, incluso si obtiene un 403 o un 404, lo que ralentiza todo (incluso ralentiza el tiempo de generación de estilo de imagen | caché | y errores 404 en los archivos serían amanecer lento solo para decirte que el archivo no existe).
