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.
