¿Cómo puedo mejorar los tiempos de respuesta del muelle?

Question

Estoy intentando acelerar el embarcadero de prueba (para compararlo con el uso de apache) para servir contenido dinámico.

Estoy probando esto utilizando tres subprocesos de cliente solicitando nuevamente tan pronto como una respuesta regrese. Se están ejecutando en un recuadro local (OSX 10.5.8 mac book pro). Apache está casi listo para usar (distribución XAMPP) y he probado Jetty 7.0.2 y 7.1.6

Apache me está dando vueltas: tiempos de respuesta hasta 2000 ms, pero un promedio de 50 ms, y si elimina los picos (alrededor del 2%) el promedio es de 10ms por llamada. (Esto fue para una página de PHP hola mundo)

Jetty no me da picos, pero los tiempos de respuesta de alrededor de 200ms.

Esto estaba llamando al localhost: 8080/hello/que se distribuye con embarcadero, y embarcadero que comienza con java -jar start.jar.

Esto me parece lento, y me pregunto si simplemente estoy haciendo algo mal.

Cualquier sugerencia sobre cómo obtener mejores números de Jetty sería apreciada.

Gracias

Answer 1

Bueno, ya que estoy funcionando con éxito un sitio con algo de tráfico en el embarcadero, estaba bastante sorprendido por su observación.

Así que simplemente probé tu prueba. Con el mismo resultado

Así que descompilé el Hello Servlet que viene con Jetty. Y tuve que reír - lo que realmente incluye siguiente línea:

Thread.sleep(200L); 

Puede see por sí mismo.

Mi propia experiencia con el rendimiento del embarcadero: me encontré con múltiples pruebas de carga roscado en mi aplicación en el mundo real donde tenía una capacidad de aproximadamente 1.000 solicitudes por segundo en mi estación de trabajo dev ...

Answer 2

Speedup o ajustar el rendimiento de cualquier aplicación o servidor es realmente difícil de conseguir hecho en mi experiencia. Necesitará comparar varias veces con diferentes modelos de trabajo para definir cuál es su carga pico. Una vez que defina la carga máxima para la mezcla de configuración/entorno que necesita sintonizar y comparar, es posible que deba ejecutar más de 5 iteraciones de su punto de referencia. Compruebe la configuración de apache/jetty en términos de número de subprocesos de trabajo para procesar la solicitud y haga que coincidan si es posible. He aquí algunas recomendaciones:

1. considerar las diferencias de los dos ambientes (GC en el embarcadero, tenga en cuenta el ajuste que MIN y el umbral máximo de memoria con el mismo tamaño y posteriormente proceder a ejecutar la prueba)
2. La carga debe venir de otra caja. Si no tiene una segunda caja/PC/servidor, tome su CPU/núcleo en cuenta y configure su prueba en una CPU específica, haga lo mismo para embarcadero/apache.
3. Esto se debe a que no puede obtener otra máquina como agente de estrés. Ejecutar modelo de varias cargas de trabajo

Pasando a modelar la prueba haga lo siguiente: 2 etapas

1. un hilo para cada configuración durante 30 minutos.
2. Comience con 1 hilo y suba hasta 5 con un intervalo de 10 minutos para aumentar el recuento,
3. Base en las métricas La Etapa 2 define una cantidad de hilos para la prueba. y ejecute ese número de hilo concurrente durante 1 hora.

correlacionar la métrica (tiempos de respuesta) de la aplicación de pruebas al servidor que aloja los recursos de la aplicación (uso sar, la parte superior y otros comandos Unix para realizar un seguimiento de la CPU y la memoria), algún otro proceso podría estar afectando te aplicación. (la memoria es relevante para apache jetty será una restricción para la configuración de memoria JVM por lo que no debería cambiar el uso de la memoria una vez que el servidor esté funcionando)

Answer 3

Tenga en cuenta el compilador de zonas activas.

Los métodos deben llamarse varias veces (¿1000 veces?) Antes de compilarse en el código nativo.

Answer 4

Definitivamente, deberías consultarlo con un generador de perfiles. Aquí están las instrucciones de cómo configurar perfiles remoto con embarcadero:

http://sujitpal.sys-con.com/node/508048/mobile

Answer 5

Tenga en cuenta también que la velocidad la prueba es realmente solo una prueba de latencia, que está bien siempre que sepa lo que está midiendo. Pero Jetty compensa la latencia para el rendimiento, por lo que a menudo hay servidores con menor latencia, pero también un rendimiento menor.

El tráfico realista para un servidor web no es 3 conexiones muy ocupadas - 1 navegador abrirá 6 conexiones, por lo que representa la mitad de un usuario. El tráfico más realista es de cientos o miles de conexiones, cada una de ellas en su mayoría inactivas.

tener una lectura de mis blogs sobre este tema: https://webtide.com/truth-in-benchmarking/ y https://webtide.com/lies-damned-lies-and-benchmarks-2/