如何对服务器推送事件进行负载测试？

Question

我有一个发送服务器发送事件的小应用程序。我想要对我的应用程序进行负载测试，以便可以基准测试从推送消息到接收消息所需的延迟时间，以便我可以知道性能在何时/何处发生故障。有哪些工具可用于执行此操作？

- Andrew

Answer 1

由于 Server-Sent Events 只是 HTTP，因此您可以使用 siege 工具。以下是示例：

siege -b -t 1m -c45 http://127.0.0.1:9292/streaming

参数解释:

• -b 压测模式，即连接之间不等待
• -t 1m 进行 1 分钟的压测
• -c45 并发连接数量为 45
• http://127.0.0.1:9292 开发服务器的主机和自定义端口
• /streaming HTTP 端点响应内容类型为 Content-Type: text/event-stream

输出结果:

Lifting the server siege...      done.

Transactions:                 79 hits
Availability:             100.00 %
Elapsed time:              59.87 secs
Data transferred:           0.01 MB
Response time:             23.43 secs
Transaction rate:           1.32 trans/sec
Throughput:             0.00 MB/sec
Concurrency:               30.91
Successful transactions:          79
Failed transactions:               0
Longest transaction:           30.12
Shortest transaction:          10.04

- sashaegorov

---

我正在尝试使用Siege服务器发送事件，当我运行以下命令时"siege -c2 -d10 -t30s http://streaming_end_point"，基本上所有返回值都是0，但实际上连接已成功建立，有任何想法吗？ - Sai

Lifting the server siege... Transactions: 0 hits Availability: 0.00 % Elapsed time: 29.61 secs Data transferred: 0.00 MB Response time: 0.00 secs Transaction rate: 0.00 trans/sec Throughput: 0.00 MB/sec Concurrency: 0.00 Successful transactions: 0 Failed transactions: 0 Longest transaction: 0.00 Shortest transaction: 0.00 - Sai

@Sai，这很奇怪，请您发布开发服务器日志好吗？另外，将 --verbose 选项传递给 siege 可以提供一些信息。 - sashaegorov

谢谢您的回复，我非常感激。我尝试使用--verbose运行siege，但无法获取有关为什么返回所有内容为0的信息。我验证了DEV日志，并能够看到流式端点按照-c值中提到的次数执行，每个请求都将与UUID相关联，我能够在日志中看到UUID，但是没有从siege中获取任何数据。我使用的siege版本是SIEGE 4.0.2。 - Sai

我创建了一个问题http://stackoverflow.com/questions/40048289/how-to-loadtest-server-sent-events，其中包含有关服务和SSE的更多详细信息。我还分析了GATLING工具以执行SSE的负载测试，并在此处找到了一些信息http://gatling.io/docs/2.2.2/http/sse.html。另一方面，当我使用siege针对普通的请求/响应时，它像魅力一样工作，但对于这个特定的流端点，它不返回任何值。 - Sai

Answer 2

我采取了一个简单的方法，创建一个shell脚本来启动N个后台作业，这些作业通过cURL连接到我的服务的SSE端点。

要获取精确的cURL语法，请打开您的Chrome Web开发工具->网络选项卡->右键单击向SSE端点的请求条目，并从上下文菜单中选择“复制为cURL”。

然后将该命令粘贴到大致类似于以下内容的shell脚本中：

#!/bin/bash

i=0;
while [ $i -lt 50 ] ;do
    [PASTE YOUR cURL COMMAND HERE] -s -o /dev/null &
    i=`expr $i + 1`;
done

每次运行此命令将添加50个后台cURL作业。请注意，我在Chrome的cURL命令中添加了参数-s -o /dev/null。这是为了以静默模式运行cURL并抑制任何输出。

在我的情况下，该服务是使用NodeJs实现的，因此我使用process.hrtime()进行高精度计时，以测量循环遍历N个连接客户端以广播数据的延迟。

结果还不错：它在约0.02秒内提供了1000多个活动连接。

请记住，如果您从同一台机器上运行服务器+cURL客户端，则可能会达到操作系统的打开文件限制。要查看Linux框（常见情况为1024）的打开文件限制，请运行：

$ ulimit -n

为了避免达到我所拥有的1000多个活动cURL，你可以：

• 从多台机器上启动它们
• 或者增加此限制（请参阅sysctl）

我面临的问题是，最终节点会因为ELIFECYCLE错误而崩溃，而日志在诊断问题方面并不是很有帮助。欢迎提出任何建议。

- Thalis K.