Aplicación web de transacciones de alto volumen basadas en Java

Question

No tengo prácticamente ninguna experiencia en el tratamiento de sitios web transaccionales de gran volumen y recientemente me encontré con esta pregunta interesante. Estoy interesado en saber dónde ocurrirían los cuellos de botella en una aplicación web Java a gran carga (miles de solicitudes por segundo). Si alguien pudiera darme un enfoque de alto nivel para pensar sobre la siguiente pregunta, ¡sería genial!

Lo único que se me ocurre es usar memcached para almacenar en caché las búsquedas en la base de datos, pero no sé cómo calcular la cantidad de tiempo que tomará cada solicitud y, por lo tanto, cuántas solicitudes por segundo el sistema podría ser capaz de manejar.

Pregunta: Las aplicaciones de escala de Internet se deben diseñar para procesar grandes volúmenes de transacciones. Describa un diseño para un sistema que debe procesar un promedio de 30,000 solicitudes HTTP por segundo. Para cada solicitud, el sistema debe realizar una búsqueda en un diccionario de 50 millones de palabras, utilizando una palabra clave pasada a través de la cadena de consulta de URL. Cada respuesta consistirá en una cadena que contiene la definición de la palabra (100 bytes o menos).

Describa los componentes principales del sistema y observe qué componentes deben ser personalizados y qué componentes podrían aprovechar las aplicaciones de terceros. Incluye estimaciones de hardware para cada componente. Tenga en cuenta que el diseño debe incluir un rendimiento máximo con los costes mínimos de licencia de hardware/software.

Documente el motivo para llegar a las estimaciones.

Describa cómo cambiaría el diseño si las definiciones son de 10 kilobytes cada una.

Answer 1

Como fondo, puede observar marcas como specmarks. En comparación con su escenario, hay un procesamiento significativamente mayor, pero verá que su 30,000 req/seg es una cifra comparativamente alta, pero no increíblemente alta.

También puede encontrar Joines et al útil. (Negación: son colegas.)

En el escenario que se puede esperar en el orden de costo decreciente:

1. recuperación de base de datos
2. actividad de la red de lectura y solicitudes que regresan
3. procesamiento simple

No está haciendo un procesamiento complejo (por ejemplo, renderizado gráfico o matemáticas de tipo ciencia espacial). Entonces, primero adivine: si su diccionario fuera una base de datos, entonces el costo de hacer una consulta va a dominar todo lo demás. Tradicionalmente, cuando llegamos a cuellos de botella en el nivel del servidor Web/App escalamos añadiendo más instancias, pero si la base de datos es el cuello de botella, eso es más un problema. Entonces, una dirección: ¿qué rendimiento puede esperar de un motor de base de datos hace que 30k tps parezcan factibles?

Su primera observación: el material de caché es una estrategia comúnmente utilizada. Aquí tiene (presumiblemente) coincidencias aleatorias en todo el diccionario, por lo tanto, el almacenamiento en memoria caché de servidores recientes en sí mismo probablemente no ayude, a menos que ... ¿puede almacenar todo en caché?

50,000,000 * (100 + gastos generales) == ??

En una JVM de 64 bits en un sistema operativo de 64 bits, ¿es posible?

Si no (y como los datos son muy grandes, entonces probablemente no) entonces tenemos que escalar. Por lo tanto, se puede utilizar una estrategia de cortar el caché. Tener (por ejemplo) 4 servidores, que sirven A-F, G-M, N-P, T-Z respectivamente (y, nota, 4 cachés separados o 4 bases de datos separadas). Haga que un despachador dirija las solicitudes.

Answer 2

Lo primero que haría es cuestionar los números. El inglés tiene aproximadamente 170,000 palabras de uso común. Agregue todos los otros lenguajes comunes y no tendría más de un par de millones. Si no es así, podría almacenar en caché las palabras más comunes en un caché rápido y las palabras menos comunes en un caché más lento. Incluso con 30 000 solicitudes por segundo, tomaría aproximadamente 30 minutos obtener cada palabra adecuada.

Básicamente, no tiene sentido diseñar un sistema grande si los números no son reales.

En una JVM de 64 bits esto cabe fácilmente. 50 millones * (100 + gastos generales) es de aproximadamente 10 GB (la sobrecarga es como estar alta ya que necesita tener la clave e indexar los datos) Un servidor de 12 GB cuesta alrededor de $ 2,500.

El problema es como el número de solicitudes. Tendrá que tener varias máquinas, pero como otros carteles han sugerido, es muy poco probable que los números sean reales. No creo que este servicio sea tan caro como Facebook, pero es probable que necesite decenas o cientos de servidores para admitir estas muchas solicitudes.