Pregunta:
Tengo un sitio que consta principalmente de páginas html estáticas con solicitudes ajax ocasionales. El sitio se ejecuta en Apache, ajax lo maneja Tomcat.
Si Tomcat se vuelve lento para responder (java no puede conectarse a un servidor de base de datos, o simplemente tarda mucho en procesar una solicitud por cualquier motivo), todo el sitio se cae: todas las páginas html estáticas tardan mucho en cargarse (lo mismo con imágenes, css, js).
Ahora, si detengo manualmente el Tomcat, todo sigue funcionando bien: el sitio es rápido y responde, solo las solicitudes ajax no funcionan.
¿Cómo puedo hacer que Tomcat de respuesta lenta no use todos los recursos de Apache, de modo que las páginas estáticas siempre funcionen sin importar lo que esté sucediendo con Tomcat? Las páginas html receptivas son mucho más importantes que no trabajar con ajax en mi caso.
httpd.conf :
Timeout 120
KeepAlive Off
MaxKeepAliveRequests 100
KeepAliveTimeout 15
<IfModule prefork.c>
StartServers 16
MinSpareServers 10
MaxSpareServers 40
ServerLimit 512
MaxClients 512
MaxRequestsPerChild 4000
</IfModule>
trabajadores.propiedades
worker.worker1.port=8888
worker.worker1.reply_timeout=120000
worker.worker1.socket_timeout=150000
server.xml
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8081" />
<Connector port="8888" scheme="http" protocol="AJP/1.3" redirectPort="8889" minSpareThreads="100" maxThreads="400" connectionTimeout="20000" acceptorThreadCount="2"/>
Respuesta:
si por alguna razón tomcat no maneja sus solicitudes ajax rápidamente, esto reduce la cantidad de solicitudes que su apache puede manejar. Tomcat está configurado para manejar 400 solicitudes en paralelo, y también hay un acceptCount predeterminado de 100. Por lo tanto, su tomcat puede consumir 500 solicitudes, al menos: jvm y dependiendo de la plataforma, puede haber incluso más solicitudes de conexión en cola.
worker.worker1.reply_timeout=120000
worker.worker1.socket_timeout=150000
..le dice a mod_jk que espere alrededor de 1,7 días (socket_timeout está en segundos) para operaciones de socket y 2 minutos para paquetes de redes individuales de tomcat. Debe ajustar estos valores para permitir que mod_jk devuelva un error lo antes posible si tomcat es lento.
Supongamos que sus solicitudes de ajax generalmente se procesan en un segundo con valores atípicos de hasta dos segundos. Una vez procesada, la respuesta se devuelve de inmediato. Entonces se puede establecer worker.worker1.reply_timeout=2500 , solo medio segundo más. socket_timeout puede incluso omitirse, ya que es solo un valor aproximado. socket_connect_timeout , que define cuánto tiempo puede tomar conectarse desde apache / mod_jk a tomcat, debe agregarse a worker.properties y establecerse en un valor muy bajo, por ejemplo, 100, ya que ambos se encuentran en el mismo servidor. Consulte La referencia del conector de Apache Tomcat para obtener más detalles.
Cada solicitud, que va de apache a tomcat, cuenta para lo que configuró con MaxClients en httpd.conf. Cuantas más solicitudes estén bloqueadas en Tomcat, menos podrá procesar Apache para contenido estático. Si apaga Tomcat en esa situación, el contenido estático se entrega rápidamente nuevamente, ya que libera recursos para el procesamiento de solicitudes en mod_jk y apache.
Ha configurado prefork.c worker.c en httpd.conf al mismo tiempo. Supongo que prefork.c es el activo, ya que MaxClients está configurado en 512 y esto coincidiría con sus observaciones y mi interpretación .. 😉
Decirle a mod_jk que se rinda antes en las solicitudes de larga ejecución a tomcat puede ayudar mucho, pero también debe pensar en ajustar la cantidad de solicitudes de clientes manejadas por apache ( MaxClients ) y la cantidad de solicitudes que procesa tomcat ( <connector maxThreads=... ) en paralelo. Estos números deben equilibrarse con lo que sucede durante las operaciones normales. Un poco de seguimiento de las cargas de la página puede ser útil para ver en qué proporción deben estar estos valores. El valor absoluto depende de las especificaciones de sus servidores, la situación de la red, el número de clientes, etc.
Si el número absoluto de posibles solicitudes paralelas es demasiado bajo, los usuarios se quejarán de la carga lenta de la página, mientras que no verá que su servidor está acostumbrado a su capacidad. Si es demasiado alto, utilizará más memoria de la que realmente se necesita, incluso se ralentizará y no se recuperará rápidamente de los problemas con los subsistemas, por ejemplo, la base de datos. Si apache envía muchas más solicitudes a tomcat como las procesaría a tiempo, verá que algunas de ellas se agotan mientras que otras se procesan en un tiempo aceptable. Comenzar con valores similares en apache y tomcat no es una mala idea, siempre que la configuración del tiempo de espera garantice que un gato lento o que no responde no sea una piedra de molino en el cuello de apache.