自定义 CMS 上糟糕的 Apache Bench 结果答案

【问题标题】：Terrible Apache Bench results on Custom CMS自定义 CMS 上糟糕的 Apache Bench 结果
【发布时间】：2011-11-26 18:25:35
【问题描述】：

请注意：这不是对劣质 CMS 的抱怨。

只是玩弄 Apache Bench，使用我们的自定义 CMS 得到了糟糕的结果，更确切地说，我得到了：

Requests per second:    0.37 [#/sec] (mean)

当我用一个普通的 php 文件运行另一个测试时，我得到了：

Requests per second:    4786.07 [#/sec] (mean)

使用以前版本的 CMS 进行另一项测试：

Requests per second:    6068.66 [#/sec] (mean)

网站运行良好，未检测到问题，Google 的网站管理员工具报告我们的网站速度超过 80% 的网页，我认为这很好。

测试是：

ab -t 30 -c 10 http://example.com/

也许是某种 Apache 问题？错误的.htaccess 配置或类似配置？

更新：

刚刚用套接字运行了一个简单的测试，结果相似。页面加载非常非常缓慢。如果我在另一个网站上运行我的脚本，一切都很好。

此外，还有一个关于块长度问题的small hint。（错误的 Apache 标头或行尾？）

该站点已压缩，当打开详细日志记录时，我在响应中看到以下行：

LOG: Response code = 200
LOG: header received:
HTTP/1.1 200 OK
Date: Tue, 04 Oct 2011 13:10:49 GMT
Server: Apache
Set-Cookie: PHPSESSID=ibnfoqir9fee2koirfl5mhm633; path=/
Expires: Sat, 26 Jul 1997 05:00:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Cache-Control: post-check=0, pre-check=0
Vary: Accept-Encoding
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

2ef6

总是在同一个地方，在 HTML 源代码的中间，然后又是 <!DOCTYPE HTML>。

请帮忙。

更新 #2：

刚刚使用 Rex Swain's HTTP Viewer 检查了我的 HTTP 标头并得到了以下结果：

HTTP/1.1·200·OK(CR)(LF)
Date:·Wed,·05·Oct·2011·08:33:51·GMT(CR)(LF)
Server:·Apache(CR)(LF)
Set-Cookie:·PHPSESSID=n88g3qcvv9p6irm1fo0qfse8m2;·path=/(CR)(LF)
Expires:·Sat,·26·Jul·1997·05:00:00·GMT(CR)(LF)
Cache-Control:·no-store,·no-cache,·must-revalidate(CR)(LF)
Pragma:·no-cache(CR)(LF)
Cache-Control:·post-check=0,·pre-check=0(CR)(LF)
Vary:·Accept-Encoding(CR)(LF)
Connection:·close(CR)(LF)
Transfer-Encoding:·chunked(CR)(LF)
Content-Type:·text/html;·charset=UTF-8(CR)(LF)
(CR)(LF)

你有什么不寻常的地方吗？

【问题讨论】：

你检查过服务器和CMS的日志吗？
您可能首先检查问题是来自客户端还是来自服务器端。然后通过二分法来隔离问题以隔离主要问题。
@palacsint 日志正常，一切正常。
@hornetbzz 当我在浏览器中打开站点时，一切正常（没有表现出这种弱性能的迹象）。运行 apachebench（同一台服务器或其他服务器，没有差异）或通过简单的套接字测试获得它，结果很糟糕。

标签： apache benchmarking chunked-encoding apachebench http-chunked

【解决方案1】：

如果它适用于普通网络浏览器（如您在 cmets 中提到的），则 CMS 会以不同方式处理来自 Apache Benchmark 的请求。

快速清单：

AFAIK Apache Benchmark 只发送简单的请求而不进行任何 cookie 处理，因此请尝试使用有效的 cookie 设置 -C（从 Web 浏览器复制值）。
尝试向 CMS 发送与 Web 浏览器发送完全相同的标题。使用 netcat、HttpFox 或数据包嗅探器保存有效请求的转储，并使用 -H 设置丢失的标头。
当您使用 Apache Benchmark 向其发送请求时，在服务器上配置 CMS。也许你找到了瓶颈。两个穷人的error_log 调用，在index.php（或测试脚本的入口点）的第一行和最后一行带有时间戳，可以显示PHP 脚本的速度并有助于计算Apache HTTP 服务器的开销和网络。
如果您从不同的机器运行套接字测试和浏览器测试，则可能是 DNS 问题（在 Apache 中关闭 HostnameLookups）。尝试在同一台机器上运行它们。
试试ab -k ... 或ab -H "Connection: close" ...。

我猜 CMS 在初始化会话时会进行一些代价高昂的初始化，并且会在它处理第一个请求时发生。由于 Apache Benchmark 不会将 cookie 发送回 CMS，因此它会为每个请求创建一个新会话，这是导致响应缓慢的原因。

第二个猜测是 CMS 以不同的方式处理传入的 http 标头，并且由 Apache Benchmark 发送（或缺少它们）的标头会触发一些昂贵/缓慢的处理。从 Google 的网站管理员工具的报告来看，它看起来更合适。

Apache Benchmark 发送 HTTP 1.0 请求，例如：

GET / HTTP/1.0
Host: localhost:9100
User-Agent: ApacheBench/2.3
Accept: */*

在我看来，您的服务器没有发送任何有关 Keep-Alive 设置的 http 标头，但它假定客户端在客户端使用 HTTP 1.0 时使用 keep-alive。这不是符合 RFC 的行为：

来自RFC 2616, 19.6.2 Compatibility with HTTP/1.0 Persistent Connections：

某些客户端和服务器可能希望与某些兼容
HTTP/1.0 中持久连接的先前实现
客户端和服务器。 HTTP/1.0 中的持久连接是
明确协商，因为它们不是默认行为。

默认情况下，Apache Benchmark 不使用 keep-alive，因此它会在响应到达时等待关闭套接字。服务器在空闲 15 秒后将其关闭。使用 wget 下载主页也需要 15 秒。 Wget 在请求中也使用 HTTP 1.0。

我认为这是 CMS 的 PHP 代码中的一个错误，因为 ab 在具有纯 php 文件的同一台服务器上运行良好。无论如何，您可以使用保持活动连接 (-k) 来解决它：

ab -k -t 30 -c 10 http://example.com/

或显式禁用持久连接：

ab -H "Connection: close" -t 30 -c 10 http://example.com/

但这仍然是服务器端问题，您原来的 ab 命令是正确的。

请注意，此错误可能仅影响 HTTP 1.0 客户端（如 Apache Benchmark、wget），使用常规浏览器的客户端不会注意到它。

【讨论】：

两种都试过了，可惜没有成功。只是获得了更少的 RPS（0.07/秒）
显示原始请求（来自浏览器）和 Apache Benchmark 的参数。也许只是一个错字。请检查更新。
原始测试请求是ab -t 30 -c 10 http://popnroll.hu/ ATM 正在调查您的更新。
测量错误日志中的运行时间，第一行和最后一行显示完全相同的时间戳。
试试ab -k。我不知道为什么它这么快（还）。