El consumidor #1 de memoria de los servidores de aplicaciones era… ¡El gestor de sesiones del Tomcat! Aunque parezca una perogrullada, el motivo de mi sorpresa es que nosotros no guardamos apenas datos en sesión, y en muchos casos ni siquiera usamos la sesión para nada puesto que muchas de nuestras aplicaciones son simplemente de consulta.
Así que revisando, revisando, encontré que el problema venía dado por varios factores:
- Aunque nosotros no usáramos la sesión para nada, algunas llamadas nuestras para comprobar si existía un atributo en la sesión o no, causaban que se crease la sesión sí o sí. Así que un par de if(request.getSession().getAttribute(…)) que se había colado se cambiaron por if(request.getSession(false)!=null && …) para evitar crear sesiones innecesarias.
- Debido a que ahora tenemos un cluster con “session failover” aunque a la sesión no le metas nada, ocupa un cierto tamaño que al multiplicarse en número empieza a ser significativo. Debido al mismo factor, las sesiones ocupan espacio en ambos nodos del cluster y no se con “fácilmente recoletables”.
- Dado que las sesiones son creadas “sin querer”, nadie las cierra y por tanto caducan solas agotando el tiempo máximo de vida sin actividad (session-timeout). Así que durante ese tiempo ocupan espacio en ambos servidores del cluster, inútilmente y encima no se pueden recolectar (GC).
- Dado que nuestras aplicaciones son públicas, los buscadores las recorren a menudo y en algunos casos sin reutilizar las cookies entre peticiones, así que nos crean una sesión por petición.
El resultado final, probado en un nodo antes que en otro, fue que para el mismo tráfico y uso, todo funcionaba igual pero con 1/3 menos de consumo de memoria. Además, ahora un pico de tráfico público, más difícil de controlar, no nos daría tantos problemas mientras las sesiones están esperando a expirar, como pasaba antes, ya que si se crean, el GC las puede liquidar sin problemas.
La moraleja es que aunque creas que no estas usando sesiones, puede que en realidad sí lo estés haciendo y te estén afectando más de lo que creas.
¡Un saludo y happy coding!
E.J.
Buenas.
ResponderEliminarYo tuve un problema similar con Weblogic y los WS.
Cuando un cliente invoca a un WS publicado en Weblogic, este te crea una sesión automáticamente, de la cual no tienes conocimiento y no puedes controlar.
La documentación es de la versión 7, pero en la 11g sigue sucediendo:
http://support.fairex.com/docs/wls/docs70/webserv/client.html
Un saludo
Sí, veo que lo único de lo que habla en este caso de sesiones es de si el cliente quiere o no participar en una, pero no parece decir mucho de controlarlas desde el servidor, aparte de una vaga referencia a los servlets.
ResponderEliminarPor suerte o desgracia, ni he trabajado con WL ni he tenido que trabajar con web services puros creados por superframeworks de estos que lo llevan todo por tí y luego te dejan con el culo al aire :).
Pero bueno es saberlo. Gracias por dejarte caer por aquí ;)