Blog

Mi Drupal sigue lento: optimización de Apache

06/04/2015

Durante mis años de administrador de sistemas, he escuchado a mucha gente quejarse de que Drupal es más lento que otros sistemas gestores de contenido como Joomla o Wordpress. A todos siempre les contestaba lo mismo: «si dejas la configuración por defecto, sí, va más lento, pero esto se debe a que Drupal es un sistema mucho más complejo y necesita un poco más de tiempo para hacerlo funcionar a pleno rendimiento».

Nuestra compañera Laura nos introdujo en el mundo de la optimización de Drupal con su artículo “Mi drupal va lento”, en el que se abordaban una serie de consejos básicos que todo drupalero debería conocer: gestión de cachés, carga de javascript, uso de sprites en imágenes,…

Como primer paso, estos consejos son muy beneficiosos para acelerar la carga de nuestra página web pero siempre podemos ir un poco más allá. En este artículo nos vamos a centrar en algunos ajustes de Apache muy útiles y sencillos que harán que nuestro drupal funcione bastante más rápido. Para ello, consideraremos una instalación simple, compuesta por un único servidor con Apache y MySQL en la misma máquina, suficiente para la mayoría de los casos.

Configuración de Apache para Drupal

La configuración que trae Apache por defecto suele más que suficiente para Drupal, pero es muy interesante probar los siguientes módulos: mod_expire y mod_deflate.

  • mod_expires le indica al navegador del usuario si el contenido que está solicitando y que ya tiene descargado en un acceso anterior está actualizado o no. Para calcular la validez toma como referencia el tiempo máximo de vida del contenido, configurado en el módulo de forma general o por tipo de contenido. Por ejemplo, si tenemos imágenes u otro contenido que no cambia en nuestro sitio, podemos indicar que el navegador del usuario mantenga en caché dicho contenido para evitar que lo cargue cada vez que visite nuestra web, reduciendo los datos transmitidos y mejorando el tiempo de acceso.
  • mod_deflate le indica al navegador del usuario que el servidor puede enviar la información de la página web comprimida, con lo que se reduce la cantidad de datos transmitidos y se reduce el tiempo de acceso. Es muy importante no tener habilitada la compresión de páginas en drupal y este módulo al mismo tiempo, pues se producen conflictos que ralentizan la carga del sitio. Es preferible utilizar este módulo a la compresión de páginas de drupal. En versiones antiguas de Apache (1.x o 2.0) se puede utilizar el módulo mod_gzip como alternativa a mod_deflate.

Ejemplos de configuración de Apache para Drupal

Veamos una posible configuración del módulo mod_expires, en el que se indica que las imágenes de tipo gif, png, jpg y jpeg permanezcan en caché como máximo 6 meses.

ExpiresActive On

ExpiresByType image/gif A15768000

ExpiresByType image/png A15768000

ExpiresByType image/jpg A15768000

ExpiresByType image/jpeg A15768000

Ahora veamos una posible configuración para el módulo mod_deflate en el que indicamos que comprima los ficheros tipo html, xml, css, javascript,…

# these are known to be safe with MSIE 6

AddOutputFilterByType DEFLATE text/html text/plain text/xml

# everything else may cause problems with MSIE 6

AddOutputFilterByType DEFLATE text/css text/javascript

AddOutputFilterByType DEFLATE application/x-javascript application/javascript application/ecmascript

AddOutputFilterByType DEFLATE application/rss+xml

NOTA: el navegador del usuario se encarga de manera automática de descomprimir la información recibida y mostrar la página de forma transparente para el usuario. La mayoría de los navegadores actuales soporta la recepción de contenido comprimido y si el usado no lo soportase, Apache enviaría la información de la página sin comprimir.

Si aplicáis esta configuración en vuestro servidor web, podéis recurrir a herramientas tipo Firebug o a la web WebPagetest para estudiar el comportamiento tras los cambios. Si ejecutáis el test que os proporciona WebPagetest, os mostrará un análisis de carga de la página para un primer y un segundo acceso, donde podréis observar cómo se carga la información de la página web inicialmente y para sucesivos accesos, en los que sólo se debería mostrar aquella información que no haya sido previamente cacheada. Además, en el enlace «Performance Review» podréis ver de manera detallada qué ficheros comprime y cuáles no, para valorar nuevos ajustes en los módulos.

En el siguiente artículo nos centraremos en la configuración de MySQL que será un poco más compleja que la que hemos visto hoy aquí.

También te puede gustar…

#4Vlog | El coste del error

#4Vlog | El coste del error

Nuevo vídeo blog de Agustín Cuenca, CEO de NeuroK y ASPgems, en el que nos habla del coste del error para las compañías.

ASPgems icon
C/ Sextante, 9
28023 Madrid,
España

Hablemos.

A %d blogueros les gusta esto: