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
comments
3 Respuestas a "Análisis de rendimiento y la necesidad de contratar especialistas"11:26
Buen diagnóstico. Lo interesante es cómo se puede plantear una solución desde el inicio sin tener en cuenta la carga que va a necesitar soportar. Me he encontrado con problemas similares cuando trabajé en el desarrollo de westlaw.es, y creoq ue lo más importante son dos cosas:
- Entender de verdad que hace tu aplicación con una herrameinta de profiler (tipo JProbe), y entonces te das cuenta de lo que se puede cachear, lo que haces de más, aquel buble que se hace nx2 veces de más...
- Entender cómo funciona el garbage collector, los procesos JVM, la arquitectura del servidor de aplicaciones, sus parámetros de configuración y su impacto en el sistema operativo...
Por mi experiencia, esta última lo malo es cuando esas dos cosas están separadas en perfiles muy distintos, ente gente de sistemas y de desarrollo, y no digamos ya si cada departamenteo intenta que la culpa recaiga en el otro. Afortunadamente en el desarrollo de westlaw.es eramos una piña ;)
Lo de los 500 usuarios, es curiosos si es JUSTO ese número, o es un número alrededor de ese que hace que la carga de trabajo sea insostenible.
12:17
Hay que tener en cuenta que, aparte de los problemas de rendimiento que si puede haber en un sistema, muchos desarrolladores no saben exactamente de lo que hablan ni conocen como funciona a bajo nivel lo que usan.
Por poner un ejemplo, 2000 usuarios concurrentes es una franca barbaridad de trafico y seguramente lo que quiera decir es que puede haber 2000 usuarios usando el sistema, pero para que tu aplicacion sea capaz de gestionar 2000 peticiones a la vez, ya no estamos hablando de un simple Tomcat o una BDD normal. Así que hay que definir "concurrente". Por que si haces una prueba de stress y pones 2000 threads concurrentes, no estaras simulando el trafico normal de tu aplicacion, estaras simulando un ataque DOS :). Etc.
Y como Martin, en estos casos yo siempre recomiendo que si no tienen a nadie, contraten a alguien ya que tampoco es algo que se aprenda para un dia para otro y aprender cuando tienes el problema encima y los plazos corren no es lo suyo. Y tampoco es algo que se pueda hacer en un foro o un blog, ya que requiere mucha prueba+diagnostico y observar muchas mas cosas de las que se pueden "contar" facilmente en un mensaje.
Sobre el ejemplo particular no dire nada, por que sin definir exactamente las cosas es como jugar a la ruleta. Por que no es lo mismo intentar 500 peticiones concurrentes con 25 conexiones a la BDD que simular el comportamiento de 500 usuarios normales, con sus pausas, su tiempo de pensar entre peticiones... etc.
S!
12:31
Un problema que veo constantemente es que la mayoría de los 'arquitectos' y 'desarrolladores' tienen una aproximación al problema de rendimiento equivocada: se centran en optimizar las partes en vez de ver el sistema como un todo. Y así no funciona esto.
Con una aproximación bottom-up se llega al mismo lugar que con una top-down, pero se tarda más. Creo que la aproximación bottom-up es la favorita de los ingenierios con menos experiencia ya que la incertidumbre está más controlada. Con la top-down la experiencia te ayuda a eliminar caminos ya andados en otros proyectos. Si no has andado ese camino, la incertidumbre es tan grande que se hace inmanejable.
Un consejo: si tienes un problema de rendimiento no le pidas ayuda al autor de un blog. Mejor contrátalo y que te solucione el problema y que haga de mentor de tu equipo.
Publicar un comentario