2009/08/10

Rendimiento en Drupal (I)

Recientemente hemos tenido una incidencia en un proyecto basado en Drupal debido a un problema grave de rendimiento. El site es un portal público con un gran número de accesos, y obviamente, al salir a producción emergió este problema.
Normalmente este tipo de situaciones no debería darse si se dimensionan unos benchmarks en condiciones, pero lamentablemente no fue este el caso. Un error muy común a la hora de definir benchmarks es no plantearlos adecuadamente.
Por un lado, hemos de diseñar unos casos lógicos de navegación. De poco basta definir una prueba de carga contra una home si luego la mayor parte de los usuarios se centran en dos o tres páginas concretas. Es importante, así pues, contar con una estadística de accesos al portal previo (caso de una actualización) o con una estimación lo más ajustada posible en caso de una nueva salida. Para este último caso se puede contar con un grupo de usuarios de control que, durante una temporada, hagan uso del portal para así generar un patrón de uso lo más realista posible.
Por otro lado, a la hora de diseñar los patrones de navegación es importante realizar varios patrones diferentes, incluir páginas diferentes en cada uno de esos patrones e incrementar lógicamente el número de hits sobre las páginas que van a ser accedidas con mayor frecuencia.
Todo esto y mucho más se puede realizar perfectamente con Jakarta JMeter.
Finalmente, y para el caso que nos ocupa, en el dimensionamiento de las pruebas, y este fue el GRAN ERROR, no se tuvo en cuenta que no es lo mismo un usuario anónimo que un usuario registrado. Estos últimos, por las características inherentes de Drupal, hacen que se haga flush del sistema de cachés por toda página sobre la que navegas.
El resultado es que aunque los test de carga daban un portal que podría soportar lo que fuera, a la hora de la verdad fue todo lo contrario.
En resúmen, es muy importante plantear y diseñar un sistema de pruebas de carga lo más realista posible a la hora de sacar un site a producción, especialmente cuando son sites sobre los que se va a tener una gran concurrencia.

2 comentarios:

  1. HOla MUY BUENOS TUS ARTICULOS! tengo una pregunta urgente si por favor me la puedes responder, cosniderandto tu experiencia.
    Cuanto consume de recursos (MEMORIA RAM) cachear una sola pagina usando los modulos de cache de Drupal? es posible que una sola consuma entre 20 y 30mb? gracias

    ResponderEliminar
  2. Una página en drupal puede consumir un montón de RAM. 80, 90, 100MB incluso más.
    Todo depende del número de módulos que tengas habilitados, lo cual puede llevar a tener que usar mucha RAM además de mucha CPU.
    Sin embargo, una vez cacheada la página, apenas consume nada porque queda renderizada en BBDD.
    Ahora bien, ten en cuenta que cualquier página en la cual el usuario necesite logarse o bien que contenga algún módulo "dinámico" no será cacheada, por lo que consumirá mucho.

    ResponderEliminar