Hello!
2014-06-11 19:40 GMT-07:00 Qiyu Huang:
> 抱歉打扰。
>
> 如果我使用OpenResty来进行密集型的计算任务， 比如，针对每一个http请求， 都是一段计算密集型的lua代码，或者简单点，抽象为写一个lua死循环。
>
每个请求都触发一个死循环肯定是受不了的，无论你使用何种架构，毕竟你的机器上的 CPU 资源总是比较非常有限的一种资源。
一般应对你的 CPU 计算尽可能地进行优化，控制在毫秒或者微秒级别。秒级别以上的计算延时是肯定受不了的，因为会阻塞 nginx
事件循环过长的时间。如果你的计算任务不能控制在毫秒级别及其以下，则应当做成后台的离线计算任务。前台的 nginx
只是给它喂任务，可以做成同步的，也可以做成异步的（比如通过任务队列），反正只要保持 nginx 一侧使用非阻塞 IO 就好。
> 这样的话，根据nginx的架构，是不是就破坏了nginx处处异步的任务机制（因为一个worker process
> 进程只一直在处理这个计算密集型任务或者死循环），降低了nginx的并发能力？
>
有一些基于 systemtap 的动态追踪工具可以对实际的阻塞效应进行实时的定量分析：
https://github.com/openresty/stapxx#epoll-loop-blocking-distr
不论是 CPU 计算的阻塞效应，还是源自文件 IO 的阻塞效应，抑或是 mutex 锁的阻塞效应都会包含在该工具的统计结果中。
> 这些使用nginx是不是更像是使用apache？ 是否有更好的解决方法？
>
当你通过配置更多的 nginx worker 进程（远多于 CPU 逻辑核数）时，nginx 会慢慢退化到和 Apache prefork
mpm 比较类似的模式。此时虽然各任务在 CPU使用上会更加公平，但会引入越来越高的 CPU
争用（包括上下文切换）的开销，总体的吞吐能力反而会下降。CPU
资源本身总是一个常数，浪费得越多，系统的整体吞吐能力就越差。尽量避免浪费是高性能应用设计上的关键。
nginx 在设计上主要是针对 IO 密集型的应用，所以应当尽量让 IO 和 CPU 计算尽可能多地重叠起来，此时系统的资源使用效率才会接近最优。
仅供参考。
同时抄送 openresty 中文邮件列表：https://groups.google.com/group/openresty
建议你也加入此列表并在那里讨论这样的技术细节问题，谢谢合作！
Regards,
-agentzh
