Ist die Leistung von Grails 2.0 wirklich so furchtbar niedrig?
https://stackoverflow.com/questions/8840183
-
27-10-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Ich bin etwas Neuling für Webentwicklung basierend auf JVM Stack, aber zukünftiges Projekt erfordert speziell eine JVM-basierte Webmaschine. Also fing ich an, auf etwas Boden zu suchen, um die Dinge schnell zu machen und drehte mich um, um Gral zu probieren. Die Dinge sahen aus dem Buch gut aus, aber ich habe mich entschlossen zu testen, wie dies unter Ladung funktioniert. Hier ist es:
Test -App: Befolgen Sie hier wenige Anweisungen, um es vom Boden aus zu erstellen (dauert 2 Minuten, vorausgesetzt, Sie haben bereits Gral und Tomcat installiert):
_http: //grails.org/quick+Start
Testfall (mit Apache Benchmark - wird mit Apache httpd - _http: //httpd.apache.org) geliefert:
AB.Exe -n 500 -c _http: // localhost: 8080/my -project/book/erstellen
(Hinweis: Dies wird nur 2 Eingangsfelder innerhalb des gestalteten Containers angezeigt.)Hardware: Intel i5 650 (4CORE*3,2 GHz) 8 GB RAM & Win Server 2003 x64
Das Ergebnis ist ..
Grals: 32 Req/Sek
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
(Nur 32 REQ/s mit 100% der CPU -Sättigung, dies ist zu unter meinen Erwartungen an solche Hardware.)
... Nächst ", Es gibt jsf-example2 target jsf-example2-1.0.war im Inneren).
- Testfall: AB.Exe -n 500 -c 10 _http: // localhost: 8080/jsf/backend/listing.jsp
Das Ergebnis ist ..
JSF: 400 Req/Sek.
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
... und geht schließlich Raw Dummy JSP (nur als Referenz)
JSP: 8000 REQ/SEC:
<html>
<body>
<% for( int i = 0; i < 100; i ++ ) { %>
Dummy Jsp <%= i %> </br>
<% } %>
</body>
</html>
Ergebnis:
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
...
Vermisse ich etwas? ... und Grails App kann viel besser laufen?
PS: Ich habe versucht, meine Running Grails -App mit VisualVM zu profilieren, habe aber endlose Schleife von Nachrichten wie ...
Profiler Agent: Redefining 100 classes at idx 0, out of total 413
...
Profiler Agent: Redefining 100 classes at idx 0, out of total 769
...
Und schließlich hat die App nach ein paar Minuten nicht mehr gearbeitet - so sieht es so aus, als ob Profiling -Grals nicht die Wahl für eine gute Diagnose ist.
Aktualisieren - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Zunächst muss ich adminieren, ja, ich muss RTFM - dh 'Grails Run -App' ist nicht der richtige Weg, um Gral für die Leistungsmessung auszuführen. Nach dem Kompilieren des Krieges und der Bereitstellung von Tomcat -Leistung ist es nicht so furchtbar niedrig - es ist nur niedrig. Die folgenden Metriken sind für die Parallelität von 1 Benutzer (ich wollte nur überprüfen, was die maximale Leistung des Frameworks in einem Thread und ohne schwere Ladung ist). Während ich andere verwandte Beiträge hier las, kam ich zu "http://stackoverflow.com/ Fragen/819684/JSF- und Spring-Performance-VS-Poor-Jsp-Performance "und beschlossen, den dort erwähnten Apache Wicket zu überprüfen-seine Leistung ist auch enthalten.
Anwendungsfall ist: - ab.exe -n 500 -c 1 _http: // localhost: 8080/... - Server ist Tomcat7 in vfabric tcserver dev edition mit 'Insight', das auf dem Hintergrund ausgeführt wird
---------------------- 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
Also ... trotzdem stimmt etwas mit Gral nicht. Ich habe mit TCServer (danke Karthick) eine Profilierung vorgenommen - es sieht so aus von TCServer weit entfernt von Bienen perfekt, kann aber nur für Informationen verwendet werden)
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: Es kann passieren, dass die Grundursache für schlechte Leistung in Grails 'Frühlingslibs' zugrunde liegt, wird dies genauer überprüfen.
Lösung
Führen Sie es mit Run-App aus?
http://grails.org/deployment Zustände:
"Grails sollten niemals mit dem Befehl grails run-App eingesetzt werden, da dies den Gral im" Entwicklungsmodus "mit zusätzlichem Gemeinkosten festlegt."
Andere Tipps
Versuchen Sie, Ihre Beispiel -App für Tomcat bereitzustellen. grails run-app ist nur für die Entwicklung.
In welcher Umgebung haben Sie die App gestartet? Produkt? Dev?
Verwenden Sie Gerüste?
Ich habe es auf meiner Maschine probiert (Core i7-2600k). Eine Anmeldeseite mit 4 Eingangsfeldern, dynamischen Layouts und einigen anderen Dingen. Ich habe 525 Anfragen pro Sekunde in der langsameren Entwicklerumgebung.
Ja, das ist ein Benchmark von jemandem, der nicht viel über Grals oder seine Umgebung weiß. Zunächst läuft er unter Windows. Wissen Sie, dass er schlecht im Ressourcenmanagement ist. Deshalb dient die meisten Webs/App -Dienste in Linux -Umgebungen.
Zweitens, wenn er 'AB' zum Benchmark benutzt, dann hat er nicht seinen Proxy -Cache -Setup .
Das alles sieht also nur aus wie das Benchmarking eines schlechten Setups und ein schlechtes Verständnis der Gral. Keine Straftat beabsichtigt.
