Hace unos días, una persona de la que obviamente no voy a revelar ni el nombre ni nada sobre la empresa, me enviaba un correo en el que me preguntaba consejo:
Actualmente estamos en el proceso de implementacion de una aplicacion web en java, desarrollada utilizando JSF(ICefaces) + Spring + Hibernate, se esperan de 1000 a 2000 usuarios concurrentes, la aplicacion se accede desde todo el pais, de lado de la aplicaciones hemos echo bastante tunning, ej. No Lazy loading, No n+1 select, paginacion. Tambien al JVM un poco; pero apesar de eso, cuando llegamos a 500 usuarios activos la aplicacion ya no funciona.
JSF,Spring,Hibernate
Tomcat 6.14, Pool DBCP
Solaris 10 UltraSparcT1, 16 Micro Procesadores, 8 GB de RAM
JDK 1.5
El correo sigue con algunos detalles sobre pools:
<Resource name="jdbc/dsAcreditacion" auth="Container"
type="javax.sql.DataSource"
...
maxActive="25" maxIdle="10"
<Connector port="80"
maxThreads="500" minSpareThreads="25" maxSpareThreads="250"
maxHttpHeaderSize="8192" enableLookups="false"
redirectPort="8443" acceptCount="5000" connectionTimeout="20000"
disableUploadTimeout="true" maxKeepAliveRequests="1"/>
Y finalmente las dudas:
¿cuales cree que deberian ser las configuraciones para el pool de
conecciones y para el Connector de Tomcat, para manejar 1000 o 2000
usuarios recurrentes?
¿ hay alguna relacion entre cantidad de usuarios recurrentes y tamaño de
pool ?
Este, es el tipo de preguntas que muchas empresas obligatoriamente se plantearán llegado un determinado punto. Idealmente serían preguntas que el personal de sistemas sería capaz de responder ya que son los que tendrán que mirar por dichos servidores, aunque realmente el/los Arquitectos ya las deberían haber tenido en cuenta durante el diseño de la aplicación y deberían ser conscientes de las limitaciones de la arquitectura escogida y de su capacidad para escalar, y los desarrolladores deberían estar también minimamente familiarizados con algunos conceptos.
Pero, como no todo el mundo es de color de rosa, la realidad es que muchas empresas no tienen el personal adecuado para estas tareas. Ya sea por falta de experiencia, o por venir de otras plataformas, o por lo que sea, pero el caso es que muchas veces una empresa se encuentra sin respuesta para este tipo de preguntas.
En este caso, una opción es preguntar al autor de un blog. Sin embargo, yo sólo actuaré como médico de cabecera. No puedo solucionar el problema, simplemente podría decirte que estás malito, y que tu dolor en la barriga se puede deber a una intoxicación, o podría ser algo más grave, por lo que te recomendaría ir al especialista.
Siguiendo con el ejemplo anterior, puedo decir que la capacidad de no poder despachar más de 500 usuarios con esa configuración indica un problema. Podría ser que tengas un problema con las librerías que usas (AJAX?) y que el límite de 500 threads sea lo que te esté evitando el poder servir a más usuarios; o quizás decirte que el problema puede ser un memory leak que te evite escalar; o tal vez si la base de datos va a recibir muchas peticiones concurrentes, 25 hilos pueden hacer de cuello de botella; o que alojar un único tomcat en un máquina de 8Gb es tontería siendo sólo una de las razones que el tener un heap tan grande sería contraproducente y probablemente todo funcionase mejor con 4 tomcats con 2Gb cada, o quizás incluso más.
Y no es que no quiera o que me moleste especialmente que me preguntéis, pero es que todo esto no dejan de ser recomendaciones de alguien que en este caso actua como médico de cabecera. Alguien que por la distancia y por el desconocimiento tanto del negocio como de la aplicación y su arquitectura no puede dar más que una serie de sugerencias. Alguien que estando en la empresa durante unos días podría realmente ofrecer soluciones para esos problemas pero que moralmente no puede ofrecer un juicio de valor por la distancia.
En un caso como este, y a falta de ganas o presupuesto para contratar a personal con experiencia, lo ideal es contratar un especialista durante un tiempo. Alguien que se pase unas semanas con la aplicación y te redacte un informe de evaluación del rendimiento y de ofrezca sugerencias para su mejora. Alguien que te prepare un plan de monitorización de las aplicaciones. Alguien que se siente contigo y te asesore sobre los cambios necesarios en la arquitectura para mejorar su escalabilidad, resistencia, tolerencia a fallos, etc.
Estos especialistas no tienen porque ser necesariamente baratos. Pero como sugería en mi metáfora anterior, y como pasa en la vida real: "Una cosa es ir al médico de cabecera, o quedarse en casa automedicarse y otra muy diferente es ir al especialista".
Foto vía everyplace@flickr
Shashikant01 
