load-testing - 负载测试应用程序调用外部 http 服务
问题描述
感谢您查看此问题，我有一个从 JMS 队列读取并处理消息并将处理后的消息发布到外部 http 服务的应用程序。使用 gatling 进行负载测试的最佳方法是什么。
我可以使用 gatling.jms 模拟队列负载。如何验证 POST 到外部服务。
解决方案
使用 Gatling 进行负载测试是一件相当复杂的事情。我已经做了足够多的事情来了解一些陷阱，所以这里有一些可能有用的见解：
- 您想通过网络进行测试，并且希望延迟最小化，以便最大限度地减少/消除由于网络延迟引起的延迟，以便结果显示可以多快地处理/响应传入的 HTTP 请求。因此，如果您的应用程序位于欧洲东部的云中，例如，您希望从同一位置运行测试。如果您的请求来自美国西部，则在路由来自美国错误一侧的请求时会出现很大延迟，这可能会导致您的应用程序的响应时间发生很大变化。
- 从您的服务中删除所有其他负载。如果您因为希望针对实时应用程序进行测试而无法移除负载，那么您需要进行另一个部署以针对没有活动负载的测试
- 负载测试应至少运行 45 分钟（根据我的经验），以验证您的服务可以处理负载。原因是服务器上累积无法承受的负载可能需要时间......所以你可以以 33req/s 的速度运行 40 分钟，但是当运行 45-60 分钟时，它的时间就足够了您的应用程序可以处理的内容与导致灾难性故障的原因之间的平衡倾向于失败。
笔记：
您无需进行破坏测试，但有时需要注意它是一个有用的指标。我发现在这里使用二进制搜索策略可以很好地获得峰值负载。
您应该测试的是您的应用程序可以处理您期望它在最坏的情况下收到的负载；不同的组织对于他们期望他们的应用程序能够处理多少负载有不同的容忍度。在我工作过的一些地方，他们使用了很多优化来直接减少服务器的负载，但如果这些保护措施失败，服务器预计将处理比通常负载多 10 倍的流量。在其他地方，没有进行相同的优化，而是有可用的灾难恢复系统，准备好在主应用程序出现故障时恢复。在这种情况下，应用程序只需要能够处理 2 倍的峰值负载（通过评估过去一年的日志/指标观察到）。
我主要使用 JVM 上的垃圾收集语言。我知道现在有零垃圾收集设计/功能可以帮助最小化 GC 任务累积的影响......所以几乎总是可以通过语言/内存设置、数据库索引或在你的在您开始更改硬件之前，应用程序本身或您用来有效执行任务的策略。
可以从日志/指标系统评估峰值负载