Recomiendenme algo mejor que tomcat

[eduardob]

Que tal, tengo un aplicacion con tomcat, pero ya llego el punto en que con demasiados usuarios concurrentes se ve afectado demasiado el desempeño de la aplicacion, actualmente en una hora critica llegamos a tener de 5 a 10 mil usuarios, hay algun otro web server mejor que sea facil de usuar como tomcat??

[GreenEyed]

Haberlos haylos , pero antes de empezar a pensar en cambiar de contenedor web... ¿estas seguro de que es ese el problema? Las probabilidades de que sea un problema de configuración o de falta de escalabilidad por parte de la aplicación son muchisimo mayores.

Nosotros como servidor usamos Resin (de Caucho), ligero y de buen rendimiento, pero ya te digo que una versión de Tomcat moderna bien configurada no debería dar problemas de rendimiento por si misma.

S!

[eduardob]

Gracias por tu comentario, estuve revisando lo que comentas con los administradores de servidores estamos usando la version 5.5.9, y como tu mencionas no hay que echarle la culpa a tomcat, creo que también estamos con un problema de hardware, en servidor con un solo procesador con 1 giga en Ram creo que no es lo adecuado

[eduardob]

Precisando la informacion el servidor es un SUN 480 sparc con 2 procesadores y 2gb en RAM. Lo que sucede aqui es que se encolan muchas sesiones, revisando la aplicacion parece estar todo normal, pero llegan momentos que se satura y el sisrtema funciona como tortuga, lento lento, en esa situacion podemos tener 2 mil usuarios

[GreenEyed]

Unf, así a ojo es difícil adivinar cual puede ser el problema, pero los candidatos mas habituales segun esos sintomas serían:

.- Si el problema ocurre al cabo del tiempo y no por picos de trafico, pudiera ser una cuestion de memoria. Falta de ella o algun memory leak causan al cabo de un tiempo de uso que el Garbage Collector trabaje más de la cuenta y eso enlentece la aplicación.

.- Si el problema ocurre unicamente en picos de trafico y si baja el pico, el sistema se recupera, entonces es que hay un cuello de botella por algun sitio. Las conexiones a la BDD, el consumo de memoria puntual (demasiadas sesiones con datos gordos en sesion, p.e.) o problemas de contencion de recursos compartidos (algun recurso compartido que se usa durante mucho tiempo en cada peticion y retrasa las demas) son entonces los sospechosos habituales.

Para averiguarlo suele tener que usarse herramientas de diagnostico (Profilers) y de estrés, para poder hacer pruebas de carga y ver como responde el sistema. Conociendo la arquitectura y comprobando los puntos donde la cosa puede estancarse, quizá lo encontreis si es una cosa obvia (como un pool de conexiones con pocas conexiones para el trafico que teneis) pero si no, hay que entrar a saco con esas herrramientas.

Si el servidor de aplicaciones esta detras de un Apache, tambien conviene comprobar que éste está configurado para manejar un numero de conexiones simultaneas adecuado al trafico y que el S.O. tambien lo permite. Ambos suelen tener limites por defecto que a veces hay que subir.

S!

[eduardob]

Pues estamos utilizando un hilo por conexion, tal vez ahi radique algo de el problema, de eso estamos conscientes. Intentamos utilizar un pool de conexiones pero como utilizamos tablas de sesión en Oracle nos dio problemas, resulta que la sesión en la bd la toma otro usuario ya que el pool gestiona los hilos y el mismo hilo se lo da a otro usuario y la sesion en la BD queda abierta ya que es el mismo hilo y por lo tanto las tablas de sesión se estropean al tener datos de otro usuario, haciendo pruebas de stress no pudimos dar con el problema especifico, yo pienso que es de hardware como tu mencionas, creo que al garbage con la insuficiencia de memoria esta sobre trabajando, hay alguna forma o alguna herramienta que me pueda decir cuanto esta trabajando al garbage? a alguna manera de medir su desempeño?

[GreenEyed]

Para saber cuanto tiempo esta "perdiendo" la JVM en el Garbage Collector se usan los llamados "Profilers", como YourKit Java Profiler, JProfiler... NetBeans creo que tiene uno integrado pero no se si te da esa información, y el JConsole que viene con Java 6 se que te da cantidades de memoria pero creo que no te dice cuanto tiempo de CPU gasta el GC.

Lo de tener un hilo abierto por usuario/conexion/sesión se vuelve realmente un problema en cuanto aumenta el numero de sesiones simultaneas. Si teneis 2.000 usuarios conectados y eso implica 2.000 threads y 2.000 conexiones a BDD abiertas, no me extraña que tengais problemas.

De los sistemas más gordos que he visto de reserva de viajes tenian 240 conexiones abiertas simultaneamente y era contra una BDD en cluster con 3 nodos. Y con un buen tratamiento de las conexiones yo he hecho aplicaciones que servían ~30.000 peticiones/hora usando 3 conexiones a BDD (con peticiones muy cortas, eso si).

Asignar conexiones a sesiones no es una buena idea en aplicaciones web. Entiendo que las tablas de sesion en Oracle os empujen a ello, pero a ser posible buscaria una alternativa a las tablas de sesion, por que es una solución dificil de escalar.

S!