Yo soy el mantenimiento de un sitio web y actualmente cuenta con alrededor de 800 usuarios simultáneos. El plan de negocios dice que este número será 10 veces mayor en un año.

Esta es mi configuración actual:

<Connector port="8080" address="${jboss.bind.address}"
  maxThreads="500" maxHttpHeaderSize="8192"
  emptySessionPath="true" protocol="HTTP/1.1"
  enableLookups="false" redirectPort="8443" acceptCount="100"
  connectionTimeout="20000" disableUploadTimeout="true" />

<Connector port="8443" address="${jboss.bind.address}"
  protocol="HTTP/1.1" SSLEnabled="true"
  maxThreads="500" minSpareThreads="5" maxSpareThreads="25"
    scheme="https" secure="true" clientAuth="false"
    keystoreFile="${jboss.server.home.dir}/conf/ks.p12"
    keystoreType="PKCS12" connectionTimeout="20000"
    keystorePass="pass" sslProtocol="TLS" acceptCount="100" />

El promedio utilizado hilos es de aproximadamente 400 (para cada uno de http/https). Pero los picos realmente el uso de 500 hilos. Creo que voy a tener problemas cuando me 10x usuarios 🙂

  • ¿Cómo puedo ajustar esto?
  • Debo deshabilitar http mantener vivo? ¿Cómo puedo configurar keep-alive tiempo de espera?
  • Qué valores son buenas para acceptCount /maxThreads?
  • No dan suficiente información como usted rechazó perfectamente buenas respuestas por ejemplo, «por razones políticas». Estás saturando de la CPU? De la red? De lo contrario, acaba de establecer maxThreads=15000″. La velocidad de su aplicación a la libre hilos anteriores. Y (si se hizo) No hay necesidad de votar en contra de respuestas que no te gusta…
InformationsquelleAutor Marcel | 2008-11-04

4 Comentarios

  1. 4

    Creo que poner tomcat de Apache Http server es mucho más robusto y más rápido de enfoque. aquí están los pros & contras tomado de http://wiki.apache.org/tomcat/FAQ/Connectors

    ¿Por qué debería integrar Apache con Tomcat? (o no)

    Hay muchas razones para integrar Tomcat con Apache. Y hay razones por las que no se debe hacer demasiado. No hace falta decir, todo el mundo está de acuerdo con las opiniones aquí. Con la ejecución de Tomcat 5 y 6, razones de rendimiento se vuelven más difíciles de justificar. Así que aquí son los temas a discutir en la integración de la vs no.

    • De la agrupación. Mediante el uso de Apache como un front-end puede dejar de Apache actuar como puerta de acceso a su contenido a múltiples instancias de Tomcat. Si uno de su juerga de solteros falla, Apache ignora y su Administrador de sistemas puede dormir por la noche. Este punto podría ser ignorada si utiliza un hardware loadbalancer y Tomcat las capacidades de clúster.
    • Agrupación/Seguridad. También puede utilizar Apache como una puerta de entrada a los diferentes juerga de solteros para los diferentes espacios de nombres URL (/app1/, /app2/, /app3/o máquinas virtuales). La juerga de solteros pueden ser luego cada uno en un área protegida y desde un punto de vista de seguridad, usted sólo tiene que preocuparse de que el servidor Apache. Esencialmente, Apache se convierte en un smart servidor proxy.
    • De seguridad. Este tema puede influir en uno de cualquier manera. Java tiene el encargado de la seguridad, mientras que Apache tiene un mayor mindshare y más trucos con respecto a la seguridad. No voy a entrar en más detalle, pero vamos a Google a ser su amigo. Dependiendo del escenario, uno puede ser mejor que el otro. Pero también tenga en cuenta que si ejecuta Apache con Tomcat – usted tiene dos sistemas de defender, no uno.
    • Add-ons. Añadir en CGI, perl, PHP es muy natural para Apache. Sus más lento y más de un parche para Tomcat. Apache también tiene cientos de módulos que pueden ser conectados a voluntad. Tomcat puede tener esta habilidad, pero el código no ha sido escrito todavía.
    • Decoradores! Con Apache en frente de Tomcat, que puede realizar cualquier número de decoradores que Tomcat no admite o no tiene la inmediata código de apoyo. Por ejemplo, mod_headers, mod_rewrite, y mod_alias podría ser escrito para Tomcat, pero ¿por qué reinventar la rueda cuando Apache se ha hecho tan bien?
    • Velocidad. Apache es el más rápido en servir contenido estático de Tomcat. Pero a menos que usted tiene un alto tráfico de sitio, este punto es inútil. Pero en algunos escenarios, tomcat puede ser más rápido que apache. Así referencia a SU sitio.
    • Zócalo de manejo y la estabilidad del sistema. Apache tiene un mejor encaje de manejo con respecto a las condiciones de error de Tomcat. La razón principal es Tomcat debe realizar todos sus zócalo de la manipulación a través de la JVM que se necesita para ser multiplataforma. El problema es socket de optimización es una plataforma específica de la prueba. La mayoría de las veces el código java está bien, pero cuando también son bombardeados con la caída de la conexión, no válido paquetes, las solicitudes no válidas de IP no válida del Apache se hace un mejor trabajo en dejar caer estas condiciones de error que JVM basado en el programa. (YMMV)
    • Muy buen marketing para apache. Pero estoy en condiciones de servidumbre a tomcat… la política de la compañía 🙂
    • La política de la compañía niega las soluciones a los problemas obvios? Eso significa que no se permite a apache benchmark como frontend, servir contenido estático? Wow.
    • Espero que no la definen como una de marketing (no tengo ninguna de las existencias invertido en Apache), creo que este tipo de implementación (Apache como un frontend) es una configuración común y considerado como una de las mejores prácticas
    • Tenemos un 99% de contenidos dinámicos. «Con el rendimiento de Tomcat 5 y 6, razones de rendimiento se vuelven más difíciles de justificar». Queremos quedarnos con tomcat… yo solo quiero afinar las configuraciones…
  2. 1

    También me gustaría mirar en la sintonización de los subyacentes de la JVM, no sólo tomcat – echa un vistazo a esta pregunta para algunos buenos consejos, especialmente alrededor de la recolección de basura y la asignación de memoria. En mi experiencia, JVM ajuste es mucho más eficaz que la optimización Tomcat interna.

    • Gracias por tu respuesta. Pero esto no es problema. GC está muy optimizado.

Dejar respuesta

Please enter your comment!
Please enter your name here