定制CMS上糟糕的Apache测试结果

请注意：这不是对劣质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)

网站运行良好，未发现任何问题，谷歌网站管理员工具报告我们的网站速度超过80%的页面，我认为这很好

测试是：

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

也许是Apache的问题？错误的

.htaccess

配置或类似配置

更新：

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

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

站点已gzip，当启用详细日志记录时，我在响应中看到以下行：

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源代码的中间，然后<代码> < /代码>。

请帮忙

更新#2:

刚刚用检查了我的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)

---

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

如果它能很好地与普通的web浏览器配合使用（正如你在评论中提到的），CMS会以不同的方式处理来自Apache Benchmark的请求

快速检查表：

• AFAIK Apache Benchmark只发送简单的请求，没有任何cookie处理，因此尝试使用有效的cookie设置

  -C

  （从web浏览器复制值）
• 尝试向CMS发送与web浏览器发送完全相同的标题。使用netcat、HttpFox或数据包嗅探器保存有效请求的转储，并使用

  -H

  设置缺少的头
• 在使用Apache基准向服务器发送请求时，在服务器上评测CMS。也许你找到了瓶颈。在

  index.php

  （或测试脚本的入口点）的第一行和最后一行中有一个时间戳的两个穷人调用可以显示php脚本的速度有多快，并有助于计算Apache HTTP服务器和网络的开销
• 如果您在不同的机器上运行套接字测试和浏览器测试，可能是DNS问题（在Apache中关闭

  HostnameLookups

  ）。试着在同一台机器上运行它们
• 尝试

  ab-k…

  或

  ab-H“连接：关闭”…

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

第二种猜测是CMS处理传入http头的方式不同，Apache基准测试发送的头（或缺少这些头）会触发一些代价高昂/速度较慢的处理。自从谷歌网站管理员工具报告发布以来，这看起来更合适

---

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

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

在我看来，您的服务器没有发送任何关于保持活动设置的http头，但它假设当客户端使用http 1.0时，客户端使用保持活动。这不是符合RFC的行为：

发件人：

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

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

我认为这是CMS的PHP代码中的一个bug，因为

ab

在使用普通PHP文件的同一台服务器上运行良好。无论如何，您可以使用保持活动连接（

-k

）来解决此问题：

或者使用显式禁用持久连接：

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

但这仍然是服务器端的问题，您最初的

ab

命令是正确的

---

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

您是否检查了服务器和CMS的日志？您可能首先检查问题是来自客户端还是服务器端。然后用二分法隔离问题，以隔离主要问题。@palacsint日志正常，一切正常。@hornetbzz当我在浏览器中打开站点时，一切正常（没有表现出性能不佳的迹象）。运行apachebench（同一台服务器或另一台服务器，没有差异）或通过简单的套接字测试获得结果都很糟糕。尝试了这两种方法，但不幸的是，都没有成功。只是得到了更少的RPS（0.07/秒）来显示原始请求（来自浏览器）和Apache基准的参数。也许只是打字错误。请检查更新。原始测试请求是

ab-t30-c10http://popnroll.hu/

ATM正在调查您的更新。在错误日志中测量运行时间，显示第一行和最后一行完全相同的时间戳。请尝试

ab-k

。我还不知道为什么它会这么快。

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