Aplicación web Java para 5000 ~ usuarios

Question

Por primera vez (con suerte no la última) en mi vida desarrollaré una aplicación que tendrá que manejar una gran cantidad de usuarios (alrededor de 5000) y administrar gran cantidad de datos. He desarrollado una aplicación que maneja muchos datos (alrededor de 100 ~ GB de datos, no tanto para muchos de tus estándares), pero el recuento de usuarios era bastante bajo (alrededor de 50).

Aquí está la lista de herramientas/marcos creo que va a utilizar: Marco

• Vaadin IU
• Hibernate
• PostgreSQL
• Apache Tomcat
• Memcached (para manejo de sesión)

La aplicación será principalmente b Correr dentro de una red de la empresa. Puede ejecutarse en un grupo de servidores o no, depende de la cantidad de dinero que la compañía quiera gastar para facilitarle la vida.

¿Qué piensas de mis elecciones y de qué debo tomar precaución?

Saludos

Answer 1

La respuesta, al igual que con todos los problemas relacionados con el rendimiento/escalabilidad es: depende.

No hay nada en su marco de elección que me lleve a pensar que no podrá manejar una gran cantidad de usuarios. Pero sin saber qué es exactamente lo que quiere hacer o cuál es su presupuesto, es imposible elegir una tecnología.

Para garantizar que la aplicación va a escalar/realizar, consideraría lo siguiente:

• Mantener el consumo de memoria de cada mínimo de la sesión. Por ejemplo, el almacenamiento en caché en el HttpSession puede funcionar cuando tiene 50, pero no es una buena idea cuando tiene 5000 sesiones.
• Haz todo el trabajo que puedas en la base de datos para reducir la cantidad de datos que se están moviendo (p. Ej. Al mirar tablas con muchas filas, asegúrate de que la paginación se hace en la base de datos (en lugar de que conseguir 10.000 filas de nuevo a Tomcat y luego recoger los primeros 10 ...)
• tratar de minimizar el estado que ha de mantenerse dentro de la HttpSession, esto hace que sea más fácil de clúster.

Probablemente el más recomendaciones importantes:

• Use load testi ng herramientas para simular su carga máxima y más allá y probar. JMeter es la herramienta que uso para el rendimiento/prueba de carga.

Cuando las pruebas de carga, asegúrese de:

• que realmente utiliza 5000 usuarios (por lo que 5000 HttpSession s se crean) y el uso de una amplia gama de datos (para evitar golpear siempre la memoria caché).

EDIT:

No creo que 5000 usuarios que no es mucho y es posible que (en cuanto al rendimiento) sólo es necesario un único servidor (depende del tamaño del servidor y los resultados de la prueba de carga, por supuesto, y puede considerar una solución en clúster para failovers de todos modos ...) para manejar la carga (es decir, no todos sus 5000 usuarios presionarán un botón al mismo tiempo, verán que sube la carga) en la mañana (es decir, todo el mundo inicia sesión).

Answer 2

recomiendo Glassfish para servidor de aplicaciones Apache Tomcat, porque puede servir contenido simple. Y Glassfish tiene una implementación completa de la especificación Java EE.

Answer 3

Es posible que desee considerar un servidor HTTP Apache en frente de sus servidores Tomcat. Apache proporcionará: compresión, almacenamiento en caché estático, equilibrio de carga y SSL.

Answer 4

Como le pediste a las personas que pesaran, no retendré mi opinión. Los ORM en general, y Hibernate en particular, son un antipatrón. Lo sé, he trabajado en tiendas que usan Hibernate en los últimos 9 años. Sabiendo lo que sé ahora, nunca lo volveré a usar.

recomiendo encarecidamente esta entrada del blog, ya que pone de forma más sucinta de lo que puede:

ORM is an anti-pattern

Pero perdóname si cito el bit de ese blog sobre ORM y anti-patrones:

la razón por la que llamo ORM un anti-patrón es porque coincide con los dos criterios el autor de antipatrones utiliza para distinguir anti-patrones de meros malos hábitos, en concreto:

• En un principio parece ser beneficiosa, pero en el largo plazo tiene más consecuencias malas que buenas
• Una solución alternativa existe que está probada y repetibles

Sus otras opciones tecnológicas parecen multa. Personalmente, me inclino más hacia Jetty que Tomcat. Hay una razón por la que Google lo incorpora en muchos de sus proyectos (piensen en GWT y PlayN); es una base de código más joven y creo que se desarrolló más activamente ahora que Eclipse se ha hecho cargo. Solo mi humilde opinión.

[ACTUALIZAR] Un enlace más, lectura muy larga pero al tomar decisiones arquitectónicas, la lectura es buena.

Object/Relational Mapping: The Vietnam of Computer Science

Answer 5

algún motivo para no usar Spring? Realmente se ha convertido en un estándar de facto en las aplicaciones java empresariales.

Spring ofrece una colección increíblemente potente y flexible de tecnologías para mejorar el desarrollo de aplicaciones Java empresariales que utilizan millones de desarrolladores.

La primavera es liviana y puede permanecer como una capa intermedia, conectando el vaadin e hibernando, creando una separación limpia de capas. La gestión de transacciones de primavera también es superior a la de hibernación. Sugeriré que lo haga hasta que tenga una razón importante que lo detenga.

Answer 6

Dependiendo de su especificación y sus metas futuras, quizás deje la versión normal de tomcat y vaya a Apache TomEE o mi preferencia personal de jBoss. Como yo entiendo, los EJB no son muy compatibles en la versión normal de tomcat y eso es algo muy agradable de tener cuando se quiere crear un par de servicios, algunos servicios singleton en clúster y otras cosas. Pero esto es solo mi preferencia personal, por supuesto, y si su especificación no permite un servidor de EE más avanzado, entonces debe seguir con el gato resbaladizo.