配置捕捉性能

我只是在玩Snap框架，想看看它是如何針對其他框架（在完全人爲的情況下）執行的。配置捕捉性能

我所發現的是，我的捕捉應用在約1500請求冠上/秒（應用程序是簡單的snap init; snap build; ./dist/app/app，即沒有代碼更改通過扣創建的默認應用程序。）：

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

我然後發射了Grails應用程序，它似乎如Tomcat（一旦JVM預熱）可以採取多一點的負載：

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

我猜，其中的一部分可能是Tomcat的似乎是事實保留大量的RAM，並可以保留/緩存一些方法。在這個實驗中，Tomcat使用超過700MB或RAM，而Snap幾乎沒有接近70mb。

問題，我有：

上午我比較蘋果和桔子這裏？
採取什麼措施來優化捕捉吞吐量/速度？

進一步的實驗：

然後，通過mightybyte的建議，我開始與+RTS -A4M -N4選擇實驗。該應用程序每秒能夠提供超過2000個請求（增加約25％）。

我還刪除了嵌套的模板，並從頂級tpl文件中提供了一個與之前相同的文檔。這將性能提高到每秒超過7000個請求。內存使用量上升到700MB左右。

來源

2016-05-11 zoran119

jkeuhlen的回答使您的第一個問題的相關性很好。至於你的第二個問題，你肯定可以用來調整表現。如果你看Snap的old raw result data，你可以看到我們正在運行+RTS -A4M -N4的應用程序。 -N4選項告訴GHC運行時使用4個線程。（請注意，您必須使用-threaded構建應用程序才能執行此操作。）-A4M選項設置垃圾回收器分配區域的大小。我們的實驗表明，這兩個似乎對性能影響最大。但那是很久以前的事了，GHC從那以後發生了很大的變化，所以你可能想和他們一起玩，找到最適合你的東西。如果你想做更多的實驗，This page有關於可用於控制GHC運行時間的其他命令行選項的深入信息。

去年完成了一項基準更新工作。如果您對此感興趣，請瀏覽snap-benchmarks repository中的不同分支。在一套新的基準測試中獲得更多幫助將是非常好的。

來源

2016-05-12 18:52:18 mightybyte

我絕不是這方面的專家，所以我只能真正回答你的第一個問題，是的，你正在比較蘋果和橘子（還有香蕉沒有意識到它）。

首先，它看起來像你試圖基準不同的東西，所以自然，你的結果會不一致。其中之一是示例Snap應用程序，另一個只是「一個Grails應用程序」。這些事情究竟做了什麼？你正在服務頁面嗎？處理請求？應用程序的差異將解釋性能的差異。其次，RAM使用率的差異也表明這些應用程序在做什麼的差異。 Haskell Web框架非常擅長處理大量實例，而沒有太多的RAM，其他框架（如Tomcat，如您所見）將受限於內存有限的性能。嘗試將兩個應用程序限制爲100MB，然後查看性能差異會發生什麼。

如果你想比較不同的框架，你真的需要運行一個標準的應用程序來做到這一點。 Snap使用Pong基準測試。舊測試的結果（從2011年和Snap 0.3）可以看到here。本段與您的情況極爲相關：

如果您將此與我們以前的結果進行比較，您會注意到我們遺漏了Grails。我們發現，我們之前對Grails的結果可能太低，因爲JVM沒有時間熱身。問題在於，由於某種原因，JVM熱身後，httperf無法獲取任何生成答覆/秒測量的樣本，因此它輸出0.0個答覆/秒。還有1000個connreset錯誤，所以我們決定Grails數字不夠可靠。

作爲比較，Yesod博客在大約同一時間有一個Pong基準，顯示類似的結果。你可以找到那here。如果您想嘗試運行更類似的基準測試，它們也鏈接到他們的基準代碼，它是available on Github。

來源

2016-05-11 16:01:12 jkeuhlen

配置捕捉性能

回答

相關問題