配置Snap以获得性能

时间:2016-05-11 12:32:39

标签: haskell haskell-snap-framework

我只是在玩Snap框架,想看看它是如何对抗其他框架的(在完全人为的情况下)。

我发现我的Snap应用程序在大约1500个请求/秒(该应用程序只是snap init; snap build; ./dist/app/app时最高,即没有代码更改为snap创建的默认应用程序):

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

我的问题:

  • 我在这里比较苹果和橘子吗?
  • 如何优化Snap的吞吐量/速度?

进一步的实验:

然后,根据mightybyte的建议,我开始尝试使用+RTS -A4M -N4选项。该应用程序每秒可以提供超过2000个请求(大约增加25%)。

我还删除了嵌套模板,并从顶级tpl文件中提供了一个文档(与之前大小相同)。这使性能提高到每秒7000多个请求。内存使用量上升到大约700MB。

2 个答案:

答案 0 :(得分:4)

我不是这个主题的专家,所以我只能回答你的第一个问题,是的,你正在比较苹果和橘子(还有香蕉,而没有意识到它)。

首先,看起来您正试图对不同的事项进行基准测试,所以很自然地,您的结果会不一致。其中一个是示例Snap应用程序,另一个是“Grails应用程序”。这些事情究竟是做什么的?你在服务页面吗?处理请求?应用程序的差异将解释性能的差异。

其次,RAM使用的差异也显示了这些应用程序正在做什么的差异。 Haskell Web框架非常擅长处理没有太多RAM的大型实例,其他框架(如您所看到的Tomcat)在性能上受限于RAM。尝试将两个应用程序限制为100mb,看看您的性能差异会发生什么变化。

如果你想比较不同的框架,你真的需要运行一个标准的应用程序来做到这一点。 Snap用Pong基准测试做到了这一点。可以看到旧测试的结果(从2011年和Snap 0.3)here。本段与您的情况极为相关:

  

如果您将此与我们之前的结果进行比较,您会发现我们遗漏了Grails。我们发现我们以前的Grails结果可能太低了,因为JVM没有时间进行预热。问题是,在JVM由于某种原因升温后,httperf无法从中获取任何样本以生成回复/秒测量,因此它输出0.0回复/秒。还有1000个connreset错误,因此我们认为Grails数字不够可靠而无法使用。

作为对比,Yesod博客大约在同一时间显示Pong基准,显示类似的结果。你可以找到here。如果您想尝试运行更相似的基准测试,它们也链接到他们的基准代码,它是available on Github

答案 1 :(得分:2)

jkeuhlen给出的答案与你的第一个问题有关。至于你的第二个问题,肯定有一些东西可以用来调整性能。如果您查看Snap的old raw result data,您会发现我们正在使用+RTS -A4M -N4运行该应用程序。 -N4选项告诉GHC运行时使用4个线程。 (请注意,您必须使用-threaded构建应用程序才能执行此操作。)-A4M选项设置垃圾收集器的分配区域的大小。我们的实验表明,这两个似乎对性能影响最大。但这是很久以前完成的,GHC自那时起已经发生了很大的变化,所以你可能想和他们一起玩,找到最适合你的东西。如果您希望进行更多实验,This page有关于可用于控制GHC运行时的其他命令行选项的深入信息。

去年在更新基准方面做了一些工作。如果您对此感兴趣,请查看snap-benchmarks repository中的不同分支。在一组新的基准测试中获得更多帮助会很棒。