配置 Snap 以提高性能答案

【问题标题】：Configuring Snap for performance配置 Snap 以提高性能
【发布时间】：2016-09-06 20:47:26
【问题描述】：

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

【问题讨论】：

标签： haskell haskell-snap-framework

【解决方案1】：

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

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

【讨论】：

【解决方案2】：

我绝不是该主题的专家，因此我只能真正回答您的第一个问题，是的，您正在比较苹果和橙子（还有香蕉而没有意识到）。

首先，您似乎正在尝试对不同事物进行基准测试，因此很自然，您的结果会不一致。其中一个是示例 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。

【讨论】：