Le prestazioni di Grails 2.0 sono davvero così terribilmente basse?

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

  •  27-10-2019
  •  | 
  •  

Domanda

Sono un po 'principiante per lo sviluppo web basato su JVM Stack, ma Future Project richiederà specificamente un motore Web basato su JVM. Così ho iniziato a cercare un po 'di terreno per fare le cose rapidamente e mi sono girato per provare Grails. Le cose sembravano buone dal libro, ma Beeing impressionato dal tempo di avvio davvero lungo (Grails Run-app) ho deciso di testare come funziona in carico. Ecco qui:

  • APP TEST: Segui poche istruzioni qui per farlo da terra (impiega 2 minuti supponendo che tu abbia già installato Grails e Tomcat):

    _http: //grails.org/quick+start

  • Test Case (con Apache Benchmark - Viene fornito con Apache Httpd - _http: //httpd.apache.org):

    AB.EXE -N 500 -C _Http: // LocalHost: 8080/my -project/book/create
    (Nota: questo è solo visualizzato 2 campi di input all'interno del contenitore in stile)

  • Hardware: Intel I5 650 (4core*3,2 GHz) 8 GB RAM & Win Server 2003 x64

Il risultato è ..

Grails: 32 req/sec

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/sec con il 100% della saturazione della CPU, questo è troppo al di sotto delle mie aspettative per tale hardware)

... Next - Ho provato a confrontarlo ad esempio con un'applicazione JSF fittizia simile (ne ho preso uno qui: _http: //www.ibm.com/developerworks/library/j-jsf2/ - cerca "codice sorgente con i file jar ", C'è JSF-Example2 Target JSF-Example2-1.0.War Inside),

  • Caso di prova: AB.EXE -N 500 -C 10 _HTTP: // LocalHost: 8080/JSF/Backend/List.jsp

Il risultato è ..

JSF: 400 req/sec

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

... e finalmente va in fittizio crudo JSP (solo per riferimento)

JSP: 8000 Req/sec:

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

Risultato:

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

...

Mi sto perdendo qualcosa? ... e l'app Grails può funzionare molto meglio?

PS: ho provato a profilare la mia app in esecuzione Grails con VisualVM, ma ho ricevuto un ciclo infinito di messaggi come ...

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

E infine l'app ha appena smesso di funzionare dopo pochi minuti, quindi sembra che Profiting Grails non sia la scelta per una buona diagnosi.

Aggiornare - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Prima di tutto devo admin, sì, ho bisogno di rtfm - cioè 'graals run -app' non è il modo corretto per eseguire graal per la misurazione delle prestazioni. Dopo aver compilato la guerra e averla distribuita a Tomcat Performance non è così bassa - è solo basso. Le metriche seguenti sono per la concorrenza di 1 utente (volevo solo controllare quali sono le prestazioni massime del framework in un thread e senza carico pesante) e mentre leggevo altri post correlati qui sono arrivato a "http://stackoverflow.com/ Domande/819684/JSF-e-Spring-performance-VS-Poor-JSP-performance "e ho deciso di controllare Apache Wicket menzionato lì-anche la sua prestazione è inclusa.

Il caso di utilizzo è: - AB.EXE -N 500 -C 1 _HTTP: // LocalHost: 8080/... - Il server è tomcat7 in vfabric tcserver dev edizione con "Insight" in esecuzione sullo sfondo

----------------------   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

Quindi ... comunque c'è qualcosa che non va in Grails. Ho realizzato un po 'di profilazione usando TCServer (grazie Karthick) - sembra che sia in grado di tracciare le azioni "basate su molla" e lo stacktrace interno per Grails è come seguire (per 2 richieste - Nota: le metriche non sono stabili - Scommetto precisione di tcserver lontano dall'abeare perfetto, ma può essere usato solo per l'informazione)

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)

PS: può succedere che la causa principale di cattive prestazioni nei graal sia alla base delle librerie "Spring", lo verificherà in più dettagli.

È stato utile?

Soluzione

Lo stai eseguendo con la run-app?

http://grails.org/deployment stati:

"I Grails non dovrebbero mai essere distribuiti utilizzando il comando Grails Run-App in quanto imposta Grails in modalità" Sviluppo "che ha ulteriori spese generali."

Altri suggerimenti

Prova a distribuire l'app di esempio su Tomcat. grails run-app è solo per lo sviluppo.

In quale ambiente hai iniziato l'app? Prod? Dev?

Usi le impalcature?

L'ho provato sulla mia macchina (core i7-2600k). Una pagina di accesso con 4 campi di input, layout dinamico e altre cose. Ho 525 richieste al secondo nell'ambiente Dev più lento.

Sì, questo è un punto di riferimento di qualcuno che non conosce molto di Grails o del suo ambiente; Innanzitutto è in esecuzione su Windows Know per essere cattivo nella gestione delle risorse, motivo per cui la maggior parte dei servizi Web/app serve in ambienti Linux.

In secondo luogo, se sta usando "AB" per il benchmark, allora non ha la sua configurazione della cache per procura perché dopo il primo successo, il resto dei colpi sarebbe memorizzato nella cache e ora sta andando .

Quindi tutto questo sembra solo il benchmarking di una cattiva configurazione e una scarsa comprensione dei graal. Nessuna offesa prevista.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top