-1

需要在大负载下找到服务器应用程序的性能瓶颈。应用程序由单个服务实例 (.asmx) 和不时通过 http 请求的一些文件组成。我解决这个问题的计划是 1）当服务器以某种方式开始失败时进入异常情况 2）分析性能计数器并在那个时刻记录以推断导致这种情况的调用类型。

为了开始实现这一点，我实现了一个特殊的客户端，它发出两种类型的请求并让它无限期地重复各自的周期，希望在某个时候我会在 WebMethod/GET url 请求期间出错（NB - 标准已经存在的解决方案，如 JMeter 和 WAPT由于服务使用场景的复杂性，不能使用）。到目前为止，我观察到的是服务调用中的响应时间增加以及文件加载期间的一些网络超时异常（使用抛出 OperationCanceledException 的 HttpClient，根据 -这个线程被认为是超时）。顺便说一句，这很奇怪，因为文件大小只有几 kb，服务方法每个请求返回 5-10 mb 的数据。认为“更大”的请求更有可能首先失败。
Perfmon 显示 CPU 负载增加，并且绝对没有内存峰值/泄漏。请求执行时间计数器非常随机，看起来无关紧要，队列长度始终为 0。
也就是说，看起来 IIS 可以很好地处理我的即兴 DDoS，同时使测试方法无效（响应时间增加意味着测试客户端内存中的更多活动请求这会在某些时候导致内存溢出，并且我已经在收到数据后立即刷新数据而没有对其进行任何操作）。
更多细节：服务器机器是 4x3Ghz 内核，4 Gb RAM。我每秒生成 50-100 个请求的负载，这导致 10-20 Mb/秒的带宽（测试客户端位于服务器数据中心内的 VM 上，4 Gbps NIC）。30 分钟的测试会话是服务器和客户端之间约 10-30 Gb 的纯数据传输。
我怎样才能真正让 Web 服务/IIS 关闭？

4

1 回答 1

1

首先，我不会编写自己的负载测试工具；有很多可用的。我使用过JMeter（开源）。您可以使用 JMeter（和其他类似工具）来发送 POST 和 GET参数、cookie 和其他 HTTP 标头 - 尽管不可否认，这对于复杂的情况确实具有挑战性。

接下来，确保您的问题确实是服务器，而不是其他基础设施 - 网络、路由器、防火墙等都具有最大功能，并且可能是问题的根本原因。他们中的大多数都有记录和报告工具。例如，我看到测试在达到防火墙的最大容量时报告了吞吐量问题；服务器甚至没有接近崩溃点。发生这种情况是因为我们在测试用例中包含了一个相当大的二进制文件，该文件通常由 CDN 提供。

接下来，总的来说，服务静态 HTTP 请求不太可能是问题 - IIS 确实非常擅长这一点。对于您提到的那种硬件，我希望每秒处理数千个请求。对于静态文件。

在大多数情况下，导致问题的是动态页面 - 您的 .asmx。所以，我会忽略负载测试中的所有静态文件，而专注于 .asmx。在您提到的那种硬件上，如果 asmxes 工作正常，您可能需要每秒生成数百个请求。

假设您的 Web 服务器已正确调整，并且 asmx 脚本具有合理的性能，我希望测试系统至少需要两倍的（CPU 和内存）容量，因为您的服务器必须使其达到临界点（这是基于我使用 JMeter 的经验，它不如我的 Web 应用程序高效，但确实可以轻松部署多个测试客户端）。因此，在您的情况下，我会寻找与您的服务器规格匹配的 2 台机器。

使用 JMeter（以及我使用过的几乎所有其他负载测试工具），您可以相当轻松地将多台机器用作负载测试客户端；我还使用 JMeter 使用了基于云的负载生成。

我不完全确定为什么这个经验法则是正确的——但我已经在多个项目中观察到它。

于 2013-08-30T15:12:56.030 回答