Creé un sitio D7 con un subtema Minelli. En el camino experimenté mucho con diferentes temas, diferentes módulos. En algún momento desarrollé un problema de rendimiento extraño, y ahora no sé realmente qué tema / módulo / configuración lo causó.

El problema es que cuando visito el sitio por primera vez, la primera página tarda unos 15 segundos. Entonces puedo moverme por el sitio y es muy sensible. Si lo dejo durante una hora más o menos, luego vuelvo a hacerlo, la primera solicitud vuelve a ser muy lenta.

He borrado el caché para que ese no sea el problema. Además, he desactivado temas y módulos que no estoy usando. ¡Moví el sitio a una nueva infraestructura pero el problema lo siguió!

¿A dónde voy después?

Hay tres cosas que revisaría.

Una, si está en un sitio de producción y no está editando archivos PHP, debe asegurarse de que APC esté habilitado, tenga suficiente memoria y tenga un TTL largo (puede ir con un día o nunca caducar si lo desea). También puede considerar la configuración apc.stat=0. Los documentos de APC tienen toda la información que necesita para configurar el TTL. Para elegir la cantidad de memoria, debe pegar el archivo apc.php en algún lugar protegido y monitorear el uso de memoria y las estadísticas de abandono. Ajuste la memoria APC para que su tasa de fallas sea muy baja. La lentitud inicial podría deberse a que APC está lleno y se está vaciando (IIRC, APC vuelca todo el caché cuando está lleno en lugar de emplear LRU o estrategias de caché más avanzadas).

En segundo lugar, asegúrese de tener MySQL sintonizado adecuadamente. Puede usar mysqltuner para ajustar los tamaños de su búfer. Su lentitud inicial podría deberse a la carga de tablas desde el disco y / o errores de caché de consultas. Si bien no es perfecto, mysqltuner te ayuda a avanzar en la dirección correcta.

Tercero, asegúrese de tener una verdadera estrategia cron de Drupal . Personalmente, deshabilitaría el cron automático en "admin / config / system / cron" y configuraría un crontab para que se ejecutara todas las noches. También puedes probar Elysia Cron si realmente necesitas un control más preciso sobre las cosas. De esta forma, puede ejecutar las tareas necesarias con la frecuencia que necesite, pero haga que las tareas normales se ejecuten durante la noche. Su lentitud inicial podría deberse a ejecuciones cron que suceden cada hora. Puede confirmar esto mirando cuando cron se ejecuta en "admin / reports / dblog" e intentando coincidir con su lentitud.

Ivanhoe123 probablemente tenga razón: Drupal 7 viene con 'pobre mans cron' habilitado por defecto. En resumen, significa que (de vez en cuando) cron se ejecuta antes de que Drupal muestre la página, retrasando todo.

Siempre trate de usar un trabajo cron real en los sitios de producción. Para obtener más detalles técnicos, visite http://drupal.org/cron o hable con su empresa de alojamiento.

Para deshabilitarlo, vaya a admin / config / system / cron y seleccione 'Nunca'.

El módulo Devel ofrece registro de la base de datos para verificar si tiene consultas de larga duración.

Si esto no ayuda, tome XHProf o XDebug y encuentre el código de culpabilidad. XHProf (un generador de perfiles) te dibuja un buen mapa de todas las funciones que se ejecutan en el servidor, y te dice cuáles están consumiendo más tiempo de ejecución. Por otro lado, cuando XDebug (un depurador) está configurado con un IDE como Eclipse ( ver video ), le permite profundizar en cada función que se ejecuta EN VIVO. El generador de perfiles le dará una idea de lo que se está ejecutando; mientras que el depurador le mostrará por qué se está ejecutando.

Solo por el sabor de la pregunta, inmediatamente pienso en tres (3) cosas

• MySQL Storage Engine / CPU
• Caché de Base de Datos
• Bloqueo de mesa

MySQL Storage Engine

Si no está utilizando ninguna búsqueda / indexación FULLTEXT, le recomiendo que convierta todos sus datos MyISAM en InnoDB. MyISAM no está diseñado para aprovechar múltiples CPU y múltiples núcleos. InnoDB se ha mejorado enormemente para el uso de múltiples CPU, así como para leer / escribir hyperthreading.

Aquí hay algunas publicaciones que hice sobre esto en el DBA StackExchange y en este sitio con respecto al ajuste de MySQL para el rendimiento de InnoDB

• Sep 20, 2011: Multi núcleos y rendimiento MySQL
• Sep 12, 2011: Posible hacer que MySQL use más de un núcleo
• Jun 07, 2011: ¿Cómo convierto una base de datos de MyISAM a InnoDB?
• May 26, 2011: Acerca del rendimiento de las bases de datos de subprocesos simples o multiprocesos
• Apr 15, 2011: https://drupal.stackexchange.com/questions/1715/what-would-be-the-optimal-mysql-configuration-for-a-drupal-7-site/2367#2367

Caché de Base de Datos

Otro argumento sólido para convertir todos los datos de MyISAM a InnoDB es cómo MySQL almacena en caché los datos / índices. MyISAM Storage Engine solo almacena en caché los índices. InnoDB almacena en caché datos e índices . A la luz de esto, puede asignar suficiente memoria para el InnoDB Buffer Pool para acomodar uno de los siguientes (el que sea más pequeño)

• Todos los datos e índices de InnoDB (ideal si también tiene suficiente RAM para el sistema operativo; elimina los retrasos posteriores)
• 75% de la RAM instalada (en caso de que tenga más datos / índices de InnoDB que RAM; minimiza los retrasos)

Si está utilizando MySQL 5.1, puede establecer innodb_max_dirty_pages_pct = 0. Esto aumentará ligeramente la E / S del disco, pero el InnoDB Buffer Pool se borrará lo suficiente como para permitir que los datos antiguos y las páginas de índice giren sin sobrecargas de E / S del disco. El complemento InnoDB de MySQL 5.5 y MySQL 5.1 no necesita este ajuste, ya que tiene un mejor mecanismo de descarga predeterminado de Buffer Pool.

Si usar InnoDB está fuera de discusión, es posible que deba usar memcached o barniz. Esto permite al desarrollador determinar cuánto tiempo los datos en caché residirán en la RAM del servidor. Naturalmente, esto requerirá una mejora en el desarrollo para que su aplicación tenga en cuenta la memoria caché / barniz.

Bloqueo de mesa

• InnoDB realiza el bloqueo a nivel de fila, lo que permite transacciones y lecturas sin bloqueo .
• MyISAM solo realiza el bloqueo completo de la tabla para cada INSERTAR, ACTUALIZAR y ELIMINAR .

Epílogo

No puede evitar un retraso inicial después de un reinicio de MySQL. Sin embargo, una vez que mejore MySQL utilizando las sugerencias / información antes mencionadas, ya no debería experimentar retrasos posteriores.

Usaría herramientas como YSlow o Firebug, etc. para determinar exactamente qué está sucediendo cuando carga dicha página y cuando carga dicha página inmediatamente después. Compruebe si se trata de un problema de almacenamiento en caché y, además, compruebe cómo funciona cuando accede a la página como usuario anónimo y luego como usuario autenticado. Compare esto con su configuración de rendimiento dentro de Drupal.

Si no se trata de un problema de almacenamiento en caché, utilice el registro de consultas de Devel y los registros de MySQL para ver qué sucede en la base de datos. Además, si tiene un código de operación o cachés similares para mejorar el rendimiento en el servidor, intente quitar algunos números y luego volver a encenderlos.

Parece que el cron se está ejecutando.

Verifique su configuración aquí: admin / config / system / cron

Casi dejo caer Drupal para mi último proyecto debido a esto.

Sin embargo, debe haber más de una causa. Todavía tengo que encontrar una solución 'arreglar todo' que funcione cada vez que este problema se presenta.

Syslog y Ubuntu / Debain

La primera vez que me encontré con el tiempo de carga intermitente de 15 segundos fue mientras ejecutaba drupal en sistemas basados ​​en Debian / Ubuntu (dedicados, no compartidos). Deshabilitar el módulo Syslog fue la solución para mí.

Como dijo @BetaRide, usar xDebug o algún otro perfilador PHP es extremadamente esclarecedor.

Sigue siendo un problema: una solución alternativa

En cuanto a mis otras instalaciones, todavía estoy perdido.

Este problema es más notable en mi servidor de desarrollo y en mis instalaciones de Drupal de bajo tráfico.

Como solución, he configurado un trabajo cron para cargar la página de inicio del sitio cada 60 segundos, así como el script cron de Drupal cada 300 segundos. Obviamente, esto no es óptimo, pero preferiría experimentar o experimentar el tiempo de carga de 15 segundos en lugar de un visitante humano.

Muchas personas sugieren que este problema podría estar relacionado con el bloqueo de procesos en segundo plano síncronos , particularmente relacionado con trabajos cron pesados .

Si es cierto, existe un gran par de módulos en desarrollo activo por parte de gielfeldt * que podrían eliminar este problema de inmediato, o al menos, podrían ofrecer algunas pistas y ayudar a los creadores de sitios a diagnosticar y tratar a los culpables específicos en sus casos. Ambos reemplazan los procesos sincrónicos de bloqueo con HTTP o comandos asincrónicos sin bloqueo, y ambos ofrecen informes relevantes que pueden identificar procesos problemáticos:

• El proceso en segundo plano y sus módulos incluidos permiten que la cola de procesos en segundo plano de Drupal se procese de forma asíncrona, para que no se bloqueen. Esto podría detener el problema. Además, con el módulo de servidor de proceso en segundo plano Apache incluido en el último desarrollador, hay un informe de interfaz de usuario básico pero mejorado con funciones para supervisar, desbloquear e inspeccionar los tiempos de inicio y el progreso de estos procesos. Esto podría identificar el proceso del problema.
• Ultimate Cron se basa en el proceso en segundo plano para permitir que las tareas activadas por cron tengan sus propios horarios asíncronos separados, cada uno de los cuales se puede monitorear y detener en una interfaz de usuario. Además de ser excelente para separar las tareas de reducción de rendimiento de servicio pesado de la limpieza regular de bajo costo, también le brinda un informe con información conveniente, como la duración de cada tarea individual activada por cron, cuándo se ejecutó por última vez, estado actual, etc. Esto también podría eliminar el bloqueo y / o identificar procesos problemáticos.

Ambos son módulos muy útiles de todos modos; para este problema, se pueden usar para probar la teoría (sonido muy plausible) de que los bloqueos son causados ​​por procesos de bloqueo sincrónico o ejecuciones cron. Potencialmente, podrían resolver el problema ejecutándolos de forma asincrónica en lugar de sincronizada, y también podrían ofrecer pistas sobre qué procesos específicos estaban causando la demora. (tenga en cuenta que su documentación es en gran medida un trabajo en progreso ...

Sin embargo, si no pueden configurarse para ayudar en absoluto, eso sugiere que hay más en el problema que solo procesos de fondo sincrónicos. FWIW, nunca he tenido este problema en particular en un sitio desde que conseguí que estos módulos funcionen correctamente (sin embargo, toque madera), pero lo he visto en mis sitios antes, así como en sitios de Drupal en vivo en la naturaleza.

También tenga en cuenta otros módulos de plug-in relacionados actualmente en desarrollo, por ejemplo, en casos complejos de alta intensidad, Ultimate Cron Queue Scaler , que permite la aceleración basada en el umbral, podría ayudar a reducir los problemas de rendimiento relacionados con cron.

* sin afiliación, solo soy un usuario muy impresionado de su trabajo

Como esto me está afectando una vez más, empiezo a investigar el problema. Definitivamente puedo confirmar eso

1. una llamada a drupal_cron_run()activada por el cron del núcleo del pobre agrega ~ 5 segundos al tiempo de solicitud en mi máquina de desarrollo. Esto se puede ensayar descomentando las pruebas alrededor de la llamada a drupal_cron_run()en modules/system/system.moduleensystem_run_automated_cron()
2. borrar todos los cachés agrega ~ 2s al tiempo de solicitud en mi máquina de desarrollo. Esto se puede probar haciendo drush cc ally volviendo a cargar la página.

Esto significa que configurar cron para nunca y agregar una llamada a cron a través de crontab mejora mucho la situación. Luego, golpear algunas páginas de uso frecuente para rellenar el caché mejoraría nuevamente la experiencia del usuario.

Sin embargo, no estoy seguro sobre el almacenamiento en caché. No he tocado la configuración de caché predeterminada para este sitio. Creo que drupal está reconstruyendo todos los cachés de vez en cuando, tal vez provocado por cron, pero no estoy seguro de cómo se hace. Pero un retraso de 7 segundos es más o menos lo que veo cuando llego a la página después de algunas horas.

Problemas como este pueden volverte loco y cuando había estado en situaciones similares, me ayuda a descubrir qué está causando el problema, paso a paso, y luego probarlo como un usuario anónimo y registrado. (método de capa de cebolla)

Menciona que comienza a notar el problema después de jugar con un par de temas y codificar de forma personalizada el suyo. No sé cuán complejo es su sitio ni la lógica detrás de él, pero los siguientes pasos lo ayudarán a encontrar el problema:

1. En su servidor, cree una carpeta u otra cuenta (esto podría ser mejor) donde realizará una instalación limpia de Drupal con la misma versión que está utilizando en su sitio. Luego, sin agregar ningún módulo o tema, pruebe el tiempo que le toma al sitio responder la primera solicitud y la siguiente solicitud. Si todo funciona bien, puede ignorar los problemas de configuración del servidor, si se comporta igual que su actual, tiene un error de configuración con su servidor web o base de datos.

2. Si los resultados del paso 1 son buenos y el servidor responde rápidamente y las solicitudes siguientes son igual de rápidas, instale solo el tema de su sitio actual en el sitio limpio de instalación y vuelva a probarlo. Si todo sigue respondiendo rápido, entonces su tema no es el problema y debe continuar con el paso 3; de lo contrario, debe comenzar a depurar su tema * 1.

3. Si después de las pruebas en el paso 2, el sitio aún comienza rápidamente a traer los módulos en su sitio actual y asegúrese de probar el tiempo de respuesta después de agregar y habilitar cada módulo * 2.

4. Si después de agregar el tema y los módulos el sitio sigue respondiendo rápidamente, comience a agregar la configuración, cree tipos de contenido, importe vistas, configure menús, etc. No olvide probar la respuesta del sitio después de agregar cada uno.

5. Instalación y configuración listas y el sitio aún rápido, bueno ahora trae los datos. Importar nodos, términos de taxonomía, comentarios, etc. Sé que debo sonar como un registro roto, pero siempre probar después de completar cada paso.

* 1 Temas de prueba: este proceso puede ser complicado en un tema súper elaborado, aquí hay un par de consejos:

1. Si vincula a cualquier biblioteca externa js o css, intente utilizar una copia local de la misma.

2. En su archivo template.php, verifique la función que puede tener bucles más largos o interminables, así como la función de preproceso y / o funciones de tema de enlace.

3. Verifique otro archivo de plantilla (page.tpl.php, etc.) y busque el procesamiento sin formato PHP de matrices y objetos.

4. Si utiliza "Vistas" y archivos de plantillas de vistas, compruebe también.

5. Siempre verifique las rutas, optimice las imágenes, los archivos js y css. A veces, los archivos js pueden tener una altura considerable cuando se usan varios fragmentos de código en un solo archivo.

* 2 Módulos de prueba : probar módulos es un poco diferente porque se permite el uso de manipulación pesada con PHP. Aquí hay algunos consejos:

1. Los módulos compatibles con la comunidad (CCK, Views, etc.) tienen una cola de problemas en drupal.org. Verifíquelos para ver si hay algún problema existente sobre su problema y si existe la posibilidad de que haya un parche para solucionarlo.

2. Módulo codificado personalizado propio, bueno, si lo codificó, tiene que arreglarlo, ¿no? Vuelva a verificar su codificación y compruebe el uso de las funciones en api.drupal.org, puede estar utilizando una función de overkilling en lugar de un gancho.

3. Módulo de código personalizado compartido en Internet, haga lo mismo que en el paso 2, pero esta vez también puede comunicarse con el escritor del módulo original e informarle sobre el problema.

4. Si su sitio es una actualización (D5 -> D6 -> D7) verifique los scripts de migración o actualización (generalmente en el archivo module.install), es posible que necesite un "índice" adicional en la nueva configuración de la tabla para acelerar la consulta SQL X más rápido .

5. Si siente que tiene visión de túnel sobre el problema, salga un poco y realice alguna otra actividad completamente no relacionada y luego vuelva más tarde para volver a tratar el problema.

6. Si hace ping al problema en una sección de código, pero no puede hacer cara o cruz sobre cómo solucionarlo, intente explicar qué se supone que debe hacer esa sección a una persona que no tiene idea de cómo programar o cómo Drupal funciona y funciona. Listo para ser sorpresa.

Nota: No se alarme si después de reconstruir su sitio todo comienza a funcionar como un encanto que es una de las mejores características que tienen las computadoras.

Verifique que no haya eliminado ningún módulo sin desinstalarlos. Esto provoca un retraso porque Drupal intenta encontrar los archivos pero ya no están allí.

Elimine referencias en la tabla de variables si los módulos ya no existen.

Un APM web como newrelic es la mejor herramienta para rastrear problemas de rendimiento. He tenido sitios que llaman una o dos líneas de código que hicieron cosas extrañas, cargaron matrices innecesarias en momentos extraños e hicieron otras cosas que eran bastante invisibles hasta que los localizamos con un APM.

Alguien mencionó que GoDaddy será lento. Muchas empresas de alojamiento basadas en la nube también tendrán este retraso inicial porque los servicios como AWS lo tienen. Es más barato tener servidores despriorizados automáticamente, y esos servidores requerirán uno o dos segundos para 'despertarse'.

Por ejemplo, Pagodabox tiene 3-4 segundos para el primer byte, hasta que el servidor esté felizmente despierto. De hecho, Pagodabox ha monetizado manteniendo el servidor despierto, por lo que puede pagar más para 'caffienate' su sitio.

Además, un CDN puede ayudarlo. Su servidor web / db no se cargará con páginas o imágenes en caché. Un buen tutorial aquí: http://wimleers.com/article/easy-drupal-cdn-integration-for-fun-and-profit

Y ... WebPageTest me hace feliz. http://www.webpagetest.org/ Compare los tiempos de carga en todo el planeta y con diferentes navegadores web de forma gratuita. Use esto para obtener resultados del mundo real para cualquier cambio que esté haciendo.

El problema podría estar en cualquier parte.

1. Asegúrese de no haber activado el modo de depuración en ningún tema o módulo. Por ejemplo, en muchos temas hay una opción para regenerar el registro de temas.
2. Si está ejecutando en un alojamiento compartido como Godaddy, entonces la solicitud de 15 segundos por primera vez es normal.
3. Convierta su sitio o página principal a base de código utilizando el módulo Drush CTools Export . Esto eliminará cualquier llamada a la base de datos y su sitio se ejecutará completamente desde php.
4. Si aún tiene problemas, use la configuración de desarrollo activando query logy las page timeropciones enadmin/config/development/devel . Vea cuál de los dos lleva más tiempo generar la página completa.
5. Reinicie su servidor si nada funciona.
6. En el peor de los casos, instale XHProf para ver dónde van las cosas mal.

Así es como solucioné el problema de mi instalación. No es una solución real, ya que no podría determinar la fuente exacta del problema (si existe), pero es una buena solución

1) Agregado CSS (configuración de caché). Esto redujo la latencia a la mitad

2) Establezca cron en nunca (y ejecútelo externamente) - Nota: tuve "intentando iniciar cron mientras ya se está ejecutando" errores. Creo que estaba tratando de iniciar cron en cada lanzamiento, pero como falló, la página cron no mencionó el último intento, sino el último éxito.

3) Configure un trabajo cron que llame a la página de inicio con Lynx cada 30 minutos

Todo esto en un servidor de alojamiento compartido. No es óptimo pero funciona.

Sugeriría usar un caché front-end a lo largo de las líneas del módulo Boost (suponiendo que esté en un alojamiento compartido) o Varnish. Esto funcionará mejor si los accesos a su sitio son principalmente anónimos y el contenido de la página es, en su mayor parte, no dinámico (es decir, las páginas no cambian mucho).

Estas soluciones guardan las páginas renderizadas en el primer acceso y luego sirven el html pre-renderizado en lugar de pasar por el proceso de arranque completo de Drupal, la creación de páginas y los procesos de tema, ahorrando MUCHO tiempo, especialmente en sitios ocupados pero también en sitios como usted describe qué "ve a dormir" y toma demasiado tiempo para despertarte.

El único inconveniente real es que (al menos para Boost) necesitará borrar la memoria caché cuando cambie el contenido del sitio. Si desea asegurarse de que el sitio esté completamente en caché con el contenido actual, puede ejecutar drush cc all y luego curl o wget contra el sitio completo periódicamente a través de cron.