> 你究竟配置了多少个 nginx worker 进程？连接池的大小合理不？
只配置了一个 nginx worker 进程，因为之前没理解 tcp 的 keep-alive 跟 http 的 keep-alive 的区别，所以就在网上随便找了一个配置来抄的。现在我们考虑将 keep-alive 配置大一些，使得 ( keep-alive 的配置值 x nginx worker 进程数 ）达到我们想要的并发数。这样就能保障大部分请求经过代理的时候都
不需要再重新打开 tcp 连接。
> 很好。不过建议提供 SVG 格式的火焰图。你这个 PNG 图片里损失了很多信息，不便于我“看图说话”，呵呵。
好的，我在附件里提供 : )
> 这些失败的请求是怎么回事？后端服务器的 bug?
accept4() failed (24: Too many open files)， 后端服务器采用的是一个原生的 nginx 服务器，使用默认配置，是我们 ulimit 没配置好，不是 bug 。
> 次外我不清楚你是否恰当配置了 worker_cpu_affinity 指令，这应当会很有帮助（如果正确配置了了的话）。
没有配置。现在我们连接池大小设置为 500 ，配置 worker_cpu_affinity 为 01 10，worker 数配置为 2 个， 我们的处理器是 4 核的，并且将 ab ， nginx 代理，后端部署在三台不同机器上，配置后我再测试，使用 ab -k ，requests per seconds 几乎是一样的 : ) ，看到这样的结果我们很嗨皮 and relief。3Q.
> 值得一提的，从火焰图上看，配置 lingering_close off 对于你这个 benchmark 来说或许也可以提升一些性能。
在配置了 lingering_close off 之后，似乎没有多大影响。现在代理的 requests per second 已经很接近不经代理的 requests per second 了。
> 还有，你貌似并没有回答我先前提的那个问题：“在满载时，nginx 的 CPU 使用率在 Linux 和 FreeBSD 上分别是怎样的？”
> 如果每个 nginx worker 进程的 CPU 压不满 100%，则可以考虑使用 off-CPU 火焰图再行分析：
忘记回答了，不明白满载是什么意思，以及在 FreeBSD 下如何使用这些工具也不太熟悉所以搁下了你的问题。待我研究一番之后再做回复。
On Tuesday, February 3, 2015 at 4:04:48 PM UTC+8, rong zhongjian wrote:
在Linux下，
我用一个nginx服务器反向代理到另一个nginx服务器(服务静态文件)，qps降到只有原来的三分之一。在Freebsd上，同样方式同样配置再测qps，几乎没有降低。
请问会不会是因为epoll的性能比kqueue的差一些呢?
