Konfigurieren Snap für Leistung

Question

Ich spiele nur mit dem Snap-Framework und wollte sehen, wie es gegen andere Frameworks (unter völlig künstlichen Umständen) funktioniert.

Was ich gefunden habe, ist, dass meine Snap-Anwendung etwa 1500 Anfragen an tops out/Sekunde (die App ist einfach snap init; snap build; ./dist/app/app, dh es werden keine Code-Änderungen an den Standard-App von Snap erstellt.):

$ ab -n 20000 -c 500 http://127.0.0.1:8000/           
This is ApacheBench, Version 2.3 <$Revision: 1706008 $> 
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ 
Licensed to The Apache Software Foundation, http://www.apache.org/ 

Benchmarking 127.0.0.1 (be patient) 
Completed 2000 requests 
Completed 4000 requests 
Completed 6000 requests 
Completed 8000 requests 
Completed 10000 requests 
Completed 12000 requests 
Completed 14000 requests 
Completed 16000 requests 
Completed 18000 requests 
Completed 20000 requests 
Finished 20000 requests 


Server Software:  Snap/0.9.5.1 
Server Hostname:  127.0.0.1 
Server Port:   8000 

Document Path:  /
Document Length:  721 bytes 

Concurrency Level:  500 
Time taken for tests: 12.845 seconds 
Complete requests:  20000 
Failed requests:  0 
Total transferred:  17140000 bytes 
HTML transferred:  14420000 bytes 
Requests per second: 1557.00 [#/sec] (mean) 
Time per request:  321.131 [ms] (mean) 
Time per request:  0.642 [ms] (mean, across all concurrent requests) 
Transfer rate:   1303.07 [Kbytes/sec] received 

Connection Times (ms) 
       min mean[+/-sd] median max 
Connect:  0 44 287.6  0 3010 
Processing:  6 274 153.6 317 1802 
Waiting:  5 274 153.6 317 1802 
Total:   20 318 346.2 317 3511 

Percentage of the requests served within a certain time (ms) 
    50% 317 
    66% 325 
    75% 334 
    80% 341 
    90% 352 
    95% 372 
    98% 1252 
    99% 2770 
100% 3511 (longest request) 

I dann gebrannt, um eine Grails-Anwendung, und es scheint, wie Tomcat (sobald die JVM aufwärmt) ein bisschen mehr Last aufnehmen kann:

$ ab -n 20000 -c 500 http://127.0.0.1:8080/test-0.1/book                                                  
This is ApacheBench, Version 2.3 <$Revision: 1706008 $> 
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ 
Licensed to The Apache Software Foundation, http://www.apache.org/ 

Benchmarking 127.0.0.1 (be patient) 
Completed 2000 requests 
Completed 4000 requests 
Completed 6000 requests 
Completed 8000 requests 
Completed 10000 requests 
Completed 12000 requests 
Completed 14000 requests 
Completed 16000 requests 
Completed 18000 requests 
Completed 20000 requests 
Finished 20000 requests 


Server Software:  Apache-Coyote/1.1 
Server Hostname:  127.0.0.1 
Server Port:   8080 

Document Path:   /test-0.1/book 
Document Length:  722 bytes 

Concurrency Level:  500 
Time taken for tests: 4.366 seconds 
Complete requests:  20000 
Failed requests:  0 
Total transferred:  18700000 bytes 
HTML transferred:  14440000 bytes 
Requests per second: 4581.15 [#/sec] (mean) 
Time per request:  109.143 [ms] (mean) 
Time per request:  0.218 [ms] (mean, across all concurrent requests) 
Transfer rate:   4182.99 [Kbytes/sec] received 

Connection Times (ms) 
       min mean[+/-sd] median max 
Connect:  0 67 347.4  0 3010 
Processing:  1 30 31.4  21  374 
Waiting:  0 26 24.4  20  346 
Total:   1 97 352.5  21 3325 

Percentage of the requests served within a certain time (ms) 
    50%  21 
    66%  28 
    75%  35 
    80%  42 
    90%  84 
    95% 230 
    98% 1043 
    99% 1258 
100% 3325 (longest request) 

ich vermute, dass ein Teil davon die Tatsache sein könnte, dass Tomcat scheint reservieren viel RAM und können einige Methoden speichern. Während dieses Experiments verwendete Tomcat mehr als 700 MB RAM, während Snap knapp 70 MB erreichte.

Fragen habe ich:

• Bin ich hier Äpfel und Birnen vergleichen?
• Welche Schritte würde man unternehmen, um Snap für Durchsatz/Geschwindigkeit zu optimieren?

---

Weitere Experimente:

Dann, wie vorgeschlagen, durch mightybyte, begann ich mit +RTS -A4M -N4 Optionen zu experimentieren. Die App konnte knapp über 2000 Anfragen pro Sekunde bedienen (ca. 25% Steigerung).

Ich entfernte auch die verschachtelten Templating und diente ein Dokument (gleiche Größe wie zuvor) von der obersten Ebene tpl Datei. Dies erhöhte die Leistung auf etwas mehr als 7000 Anfragen pro Sekunde. Die Speicherauslastung stieg auf etwa 700 MB.

Answer 1

Die Antwort von Jkeuhlen macht gute Beobachtungen relevant für Ihre erste Frage. Was deine zweite Frage betrifft, gibt es definitiv Dinge, mit denen du spielen kannst, um die Leistung zu optimieren. Wenn Sie Snap old raw result data betrachten, können Sie sehen, dass wir die Anwendung mit +RTS -A4M -N4 ausgeführt haben. Die Option -N4 teilt der GHC-Laufzeit mit, 4 Threads zu verwenden. (Beachten Sie, dass Sie dazu die Anwendung mit -threaded erstellen müssen.) Die Option -A4M legt die Größe des Zuordnungsbereichs des Garbage Collectors fest. Unsere Experimente haben gezeigt, dass diese beiden Faktoren den größten Einfluss auf die Leistung haben. Aber das ist schon lange her und GHC hat sich seitdem sehr verändert, also wollt ihr wahrscheinlich mit ihnen herumspielen und herausfinden, was für euch am besten ist. This page enthält ausführliche Informationen zu anderen Befehlszeilenoptionen, die zur Steuerung der Laufzeit von GHC zur Verfügung stehen, wenn Sie mehr experimentieren möchten.

Ein wenig Arbeit wurde letztes Jahr mit der Aktualisierung der Benchmarks gemacht. Wenn Sie daran interessiert sind, schauen Sie sich die verschiedenen Zweige in der snap-benchmarks repository. Es wäre großartig, mehr Hilfe bei neuen Benchmarks zu bekommen.

Answer 2

Ich bin keineswegs ein Experte auf dem Thema, so kann ich nur Ihre erste Frage wirklich beantworten, und ja, Sie vergleichen Äpfel und Orangen (und auch Bananen, ohne es zu merken).

Zunächst einmal, es sieht aus wie Sie Benchmark verschiedene Dinge versuchen, so natürlich, werden Ihre Ergebnisse inkonsistent. Eine davon ist die Beispiel-Snap-Anwendung und die andere ist nur eine "Grails-Anwendung". Was genau macht jedes dieser Dinge? Servierst du Seiten? Anfragen bearbeiten? Der Unterschied in den Anwendungen wird die Unterschiede in der Leistung erklären.

Zweitens zeigt der Unterschied in der RAM-Nutzung auch den Unterschied in was diese Anwendungen tun. Haskell-Web-Frameworks sind sehr gut im Umgang mit großen Instanzen ohne viel RAM, wo andere Frameworks, wie Tomcat, wie Sie gesehen haben, in ihrer Leistung mit begrenztem RAM begrenzt sein werden. Versuchen Sie, beide Anwendungen auf 100 MB zu beschränken, und sehen Sie, was mit Ihrem Leistungsunterschied passiert.

Wenn Sie die verschiedenen Frameworks vergleichen möchten, müssen Sie dafür eine Standardanwendung ausführen. Snap hat dies mit einem Pong-Benchmark gemacht. Die Ergebnisse eines alten Tests (ab 2011 und Snap 0.3) sind zu sehen here. Dieser Absatz ist extrem relevant für Ihre Situation:

Wenn Sie dies mit unseren vorherigen Ergebnissen vergleichen, werden Sie bemerken, dass wir Grails weggelassen haben.Wir haben herausgefunden, dass unsere vorherigen Ergebnisse für Grails möglicherweise zu niedrig waren, weil der JVM keine Zeit zum Aufwärmen gegeben wurde. Das Problem besteht darin, dass nach dem Aufwärmen der JVM aus irgendeinem Grund keine Möglichkeit besteht, dass httperf irgendwelche Samples erhält, aus denen eine Antwort/s-Messung generiert werden kann, so dass es 0,0 Antworten pro Sekunde ausgibt. Es gibt auch 1000 Connreset-Fehler, daher haben wir entschieden, dass die Grails-Zahlen nicht zuverlässig genug sind.

Zum Vergleich hat der Yesod Blog einen Pong Benchmark aus der gleichen Zeit, der ähnliche Ergebnisse zeigt. Sie können das here finden. Sie verlinken auch auf ihren Benchmark-Code, wenn Sie versuchen möchten, einen ähnlicheren Benchmark zu betreiben, es ist available on Github.