配置捕捉性能

我只是在玩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

配置捕捉性能

回答

相关问题