我有一台通过 mod_jk 代理到 Tomcat 的 Apache 服务器。我在 Apache 中设置了一个自定义日志来记录访问时间：
LogFormat "%h %l %u %t \"%r\" %>s %b %D" transfertimes
CustomLog /path/to/transfer-times.log transfertimes
我在 Web 服务器本身上运行 ApacheBench。我注意到，随着并发性的增加，99% 的请求时间似乎呈指数级增长，尽管 50% 的请求时间保持相对稳定。例如，ApacheBench 会说，在并发性级别为 100 的情况下，1000 个请求中大约有 10 个需要 1 秒以上才能响应。
但是，当我查看 transfer-times.log 时，根据 %D，没有显示任何超过 1 秒的请求日志格式。我试图找出导致 Apache 日志和 ApacheBench 报告的访问时间不一致的原因。通常我可以将其归因于网络延迟，但我在单个主机上运行这一切。我想 Linux TCP 参数或文件描述符一定有什么奇怪的地方需要调整，但我不确定从哪里开始。
答案1
实际上可能并不是 Apache 需要这么长时间来处理请求，而是您遇到了操作系统中已定义的其他限制。
看一下 netstat 提供的已接受连接数，您很可能会发现 apache 看到的请求数（因此在 apache 知道的时间范围内提供服务）和操作系统已经可以处理的请求数存在很大差异。
netstat -tulpen
可能会有所帮助。另外，看看 sysctl 告诉你的限制，或者甚至是 iptables。
很抱歉，我记不清任何细节，因为我已经很久没有遇到过这样的问题了。
答案2
我认为您的外部请求由于 apache 或 mod_jk 切换中的工作人员不足而处于接受积压状态。
要在 apache 和 tomcat 之间正确代理，您需要将 tomcat 连接器设置为处理与 apache 派生子进程相同的连接数。如果不这样做，apache 将不得不阻塞，等待 tomcat 释放连接。这可能会导致额外的阻塞，因为那些等待 tomcat 的工作人员将无法处理传入的连接。
http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html
ps. 不要将其%D视为福音。它仅测量 apache 子进程开始工作（因此不计算接受/分叉/切换持续时间）和最后一个字节发送时间send()（因此由于操作系统缓冲而变化很大）之间的时间。
pps。调整 AJP 是一门黑魔法，在我看来，AJP 的好处（稍微容易一些地解析请求、持久连接）已不足以成为避免直接 HTTP 代理的理由。