¿El rendimiento de los gros 2.0 es realmente tan terriblemente bajo?

StackOverflow https://stackoverflow.com/questions/8840183

  •  27-10-2019
  •  | 
  •  

Pregunta

Soy algo novato para el desarrollo web basado en JVM Stack, pero el proyecto Future requerirá específicamente un motor web basado en JVM. Así que comencé a mirar un terreno para hacer las cosas rápidamente y me volví para probar los gros. Las cosas se veían bien desde el libro, pero el apego impresionado por el tiempo de inicio realmente largo (Grails Run-App) decidí probar cómo funciona esto bajo carga. Aquí está:

  • Aplicación de prueba: siga pocas instrucciones aquí para llegar a la tierra (lleva 2 minutos suponiendo que ya tenga gros y Tomcat instalados):

    _http: //grails.org/quick+start

  • Caso de prueba (con Apache Benchmark - Viene con Apache httpd - _http: //httpd.apache.org):

    ab.exe -n 500 -c _http: // localhost: 8080/my -project/book/create
    (Nota: Esto es solo que muestra 2 campos de entrada dentro del contenedor de estilo)

  • Hardware: Intel I5 650 (4core*3.2GHz) 8GB RAM & WIN Server 2003 x64

El resultado es ..

Grails: 32 req/seg

Total transferred:      1380500 bytes
HTML transferred:       1297500 bytes
Requests per second:    32.45 [#/sec] (mean)
Time per request:       308.129 [ms] (mean)
Time per request:       30.813 [ms] (mean, across all concurrent requests)
Transfer rate:          87.51 [Kbytes/sec] received

(Solo 32 req/seg con el 100% de la saturación de la CPU, esta es una manera también por debajo de mis expectativas para dicho hardware)

... A continuación, intenté compararlo, por ejemplo, con una aplicación JSF ficticia similar (tomé una aquí: _http: //www.ibm.com/developerworks/library/j-jsf2/ - Busque "código fuente con archivos jar ", hay jsf-exame2 target jsf-exame2-1.0.war adentro),

  • Caso de prueba: AB.exe -n 500 -C 10 _http: // localhost: 8080/jsf/backend/listing.jsp

El resultado es ..

JSF: 400 req/seg

Total transferred:      5178234 bytes
HTML transferred:       5065734 bytes
Requests per second:    405.06 [#/sec] (mean)
Time per request:       24.688 [ms] (mean)
Time per request:       2.469 [ms] (mean, across all concurrent requests)
Transfer rate:          4096.65 [Kbytes/sec] received

... y finalmente se vuelve ficticio crudo JSP (solo como referencia)

JSP: 8000 REQ/SEC:

<html>
<body>
<% for( int i = 0; i < 100; i ++ ) { %>
Dummy Jsp <%= i %> </br>
<% } %>
</body>
</html>

Resultado:

Total transferred:      12365000 bytes
HTML transferred:       11120000 bytes
Requests per second:    7999.90 [#/sec] (mean)
Time per request:       1.250 [ms] (mean)
Time per request:       0.125 [ms] (mean, across all concurrent requests)
Transfer rate:          19320.07 [Kbytes/sec] received

...

¿Me estoy perdiendo de algo? ... ¿La aplicación Grails puede funcionar mucho mejor?

PD: Intenté perfilar mi aplicación Grails con VisualVM, pero obtuve un bucle interminable de mensajes como ...

Profiler Agent: Redefining 100 classes at idx 0, out of total 413
...
Profiler Agent: Redefining 100 classes at idx 0, out of total 769
...

Y finalmente la aplicación dejó de funcionar después de unos minutos, por lo que parece que perfilar gros no es la opción para un buen diagnóstico.

Actualizar - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

En primer lugar, tengo que administrar, sí, necesito RTFM, es decir, 'Grials Run -App' no es la forma correcta de ejecutar gros para la medición del rendimiento. Después de compilar la guerra y implementarla en el rendimiento de Tomcat no es tan terriblemente bajo, es simplemente bajo. Las métricas a continuación son para la concurrencia de 1 usuario (solo quería verificar cuál es el rendimiento máximo del marco en un hilo y sin carga pesada) y mientras leía otras publicaciones relacionadas aquí llegué a "http://stackoverflow.com/ Preguntas/819684/JSF-y-Spring-rendimiento-VS-POOR-JSP-REPORFORMANCE "y decidió verificar el wicket Apache mencionado allí: su rendimiento también está incluido.

El caso de uso es: - ab.exe -n 500 -c 1 _http: // localhost: 8080/... - El servidor es tomcat7 en vfabric tcserver dev edition con 'información' que se ejecuta en segundo plano

----------------------   tcServer       Plain Tomcat 7    -c 10
/Grails/book/create      77 req/sec     130 req/sec       410 req/sec
/jsf/backend/listing.jsp 133 req/sec    194 req/sec       395 req/sec
/wicket/library/         870 req/sec    1400 req/sec      5300 req/sec

Entonces ... de todos modos hay algo mal con los gros. He hecho algunos perfiles usando TCServer (gracias Karthick). Parece que solo es capaz de rastrear las acciones 'basadas en primavera' y la playa interna para los griales es como seguir (para 2 solicitudes - Nota: las métricas no son estables. Apuesto a la precisión de tcserver lejos de la abeja perfecta, pero se puede usar solo para la información)

Total (81ms)
    Filter: urlMapping (32ms)
        -> SimpleGrailsController#handleRequest (26ms)
        -> Render view "/book/create" (4ms)
    Render view "/layouts/main.gsp" (47ms)

Total (79ms)
    Filter: urlMapping (56ms) ->
        -> SimpleGrailsController#handleRequest (4ms)
        -> Render view "/book/create" (38ms)
    Render view "/layouts/main.gsp" (22ms)

PD: Puede suceder que la causa raíz para el mal rendimiento en los grases esté subyacente a las libres 'primavera', verificará esto en más detalles.

¿Fue útil?

Solución

¿Lo estás ejecutando con Run-App?

http://grails.org/deployment Estados:

"Los grases nunca deben implementarse utilizando el comando Grails Run-App, ya que esto establece los grases en el modo" Desarrollo "que tiene gastos generales adicionales".

Otros consejos

Intente implementar su aplicación de muestra en Tomcat. grails run-app es solo para el desarrollo.

¿En qué entorno inició la aplicación? ¿pinchar? ¿Dev?

¿Usas andamios?

Lo he probado en mi máquina (Core i7-2600k). Una página de inicio de sesión con 4 campos de entrada, diseños dinámicos y algunas otras cosas. Tengo 525 solicitudes por segundo en el entorno de desarrollo más lento.

Sí, este es un punto de referencia de alguien que no sabe mucho sobre los gros o su entorno; Primero, se está ejecutando en Windows Know por ser malo en la administración de recursos, por lo que la mayoría de los servidos/aplicaciones web se ejecutan en entornos de Linux.

En segundo lugar, si está usando 'AB' para referencia, entonces no tiene su configuración de caché proxy porque después del primer golpe, el resto de los golpes se almacenaría en caché y ahora está envolviendo su caché de mi comprensión de su configuración .

Así que todo esto se parece a la evaluación comparativa de una mala configuración y una mala comprensión de los gros. Sin ofender.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top