4

请注意：这不是对劣质 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，还是类似的？

更新：

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

此外，还有一个关于块长度问题的小提示。（错误的 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 的 HTTP 查看器检查了我的 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)

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

4

1 回答 1

4

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

快速清单：

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

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

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

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 文件的同一台服务器上运行良好。无论如何，您可以使用 keep-alive 连接 ( -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），使用常规浏览器的客户端不会注意到它。

于 2011-10-10T17:00:56.560 回答