2

我们正在使用 Jmeter 测试在 Apache 2 Web 服务器上运行的 Php 应用程序。我可以加载 Jmeter 以使用 25 或 50 个线程，并且服务器上的负载不会增加，但是服务器的响应时间会增加。线程越多，响应时间越慢。似乎 Jmeter 或 Apache 正在对请求进行排队。我已经更改了 apache web 服务器配置文件中的 maxclients 值，但这并没有改变问题。在 Jmeter 运行时，我可以使用该应用程序并获得可观的响应时间。是什么赋予了？我希望能够通过增加线程数将我的服务器的空闲率降低到 0%。谁能帮我指出正确的方向？

更新：我发现如果我从我的应用程序中删除会话，我可以模拟服务器上的全部负载。我尝试重新启用会话并为每个线程使用 HTTP Cookie 管理器，但它似乎没有产生影响。

4

3 回答 3

4

您需要确定瓶颈发生的位置，然后尝试修复问题。

  • JMeter 客户端应该在设备齐全的机器上运行。我更喜欢运行 JVM 的 Solaris/Unix 服务器，但是对于 <200 个线程，现代 Windows 机器就可以了。JMeter 可能会成为瓶颈，一旦发生，您将不会获得任何有意义的结果。此外，它应该在与您的测试不同的机器上运行，并且最好在同一网络上运行。如果您的测试平台和服务器相距甚远，WAN 延迟可能会成为一个问题。
  • 要检查的第二件事是您的 Apache 工作人员。Apache 有一个模块 - mod_status - 它将向您显示每个工人的状态。可能将您的池大小设置得太低。从 mod_status 中，您将能够看到有多少工人正在使用中。很少，Apache 将没有任何工作人员来处理请求，并且请求将排队。太多了，Apache 可能会耗尽运行它的机器上的内存。
  • 接下来，您应该检查您的数据库。如果它在单独的机器上，则数据库可能会出现 IO 或 CPU 短缺。
  • 如果您遇到瓶颈，并且服务器和数据库在同一台机器上，您通常会遇到 CPU、RAM 或 IO 限制。我按照最容易识别的顺序列出了它们。如果你得到一个 CPU 密集型应用程序，你可以很容易地看到你的 CPU 使用率达到 100%。如果您的 RAM 用完，您的机器将开始交换。在 Windows 和 unix 上，很容易看到可用的可用 RAM。最后，您可能会受到 IO 限制。这也可以使用各种工具或统计数据进行监控，但它不像 CPU 那样明显。

最后，特别是针对您的问题，突出的一件事是可以将大量会话文件存储在单个目录中。PHP 通常将会话信息存储在文件中。如果此目录变大，PHP 将花费越来越长的时间来查找会话。如果您运行测试将 cookie 关闭，PHP 应用程序可能会为每个用户请求创建数千个会话文件。在 Windows 服务器上，它会比在 unix 服务器上减速得更快，因为目录在两个操作系统上的存储方式不同。

于 2010-01-10T10:44:49.793 回答
2

您是否使用恒定吞吐量计时器？如果 Jmeter 无法使用分配给它的线程来服务吞吐量，您将在响应时间看到这种排队和井喷。要确定这是否是问题所在，请尝试添加更多线程。

我还发现了当脚本中有 javascript 调用时发生这种情况的报告。在这种情况下，尝试将 javascript 调用移动到脚本顶部的测试计划元素，或者寻找预先计算值的方法。

于 2010-05-21T13:20:21.910 回答
0

尝试检查由 apache 而不是 PHP 提供的静态文件，以查看问题出在 Apache 配置还是 PHP 配置中。

还要检查您的网络连接和配置。我们的 JMeter 测试进展顺利，直到碰壁。最终意识到我们只有一个 100Mb 的连接，而且它已经饱和了，打算用千兆位修复它。您的网卡或交换机的运行速度可能比您想象的要低，尤其是当它们的速度设置为“自动”时。

于 2010-01-10T01:36:13.347 回答