我一直在阅读这个链接： http ： //blog.martinfjordvald.com/2010/08/file-uploading-with-php-and-nginx/ （博客的post反复从官方的Nginx站点链接），它说：
每次Apache接受上传时，这些进程中的一个将在上传期间忙碌。
现在我承认我是Nginx的noob，但是也不会承受这样一个问题：在上传的时候会使用自己的工作人员，好吧，这不是一个带有RAM /它随之而来的CPU问题，但它仍然是有限的（即x连接数），对不对？
我不确定在这里使用Nginx的好处是相当的解释。
Nginx的文档本身并不是非常清楚它究竟是如何真正处理请求的，所以如果我对Nginx的工作有些不可思议的错误，那么我希望有人会修复它，而不是downvoting。
好的@ MichealHampton的链接（ http://www.aosabook.org/en/nginx.html#fig.nginx.arch ）我基本上总结一下。
首先要注意的是，Apache 2.4还引入了一些有趣的变化，即事件MPM： http ： //httpd.apache.org/docs/trunk/mod/event.html更多的是一个非阻塞版本： http ： //httpd.apache.org/docs/trunk/mod/worker.html旨在通过将工作转移到离开主线程的其他线程来创buildIO使用情况，尽可能减less摩擦自由地继续工作。
这当然不能解决Apache的基本问题，这是它的内存和CPU使用率（毕竟这是一套通用的工具），但它是一个正确的方向，并且意味着Apache不必再被阻塞但可以更asynchronous。
这意味着当然，Nginx可以处理的事情比Apache 2.4s更多，因为它使用的更less。
关于Nginx上传的主要观点是，尽pipe是单线程的，但是它的工作者能够不被绑定到单个任务上。 使用紧密循环的事件通知来处理asynchronousIO，从而使单个工作人员即使在单个工作人员上也能够进行多次（可能是1,000次）的上传。
这仍然与Apaches非事件模型形成鲜明对比，尽pipeApache和Nginx一样慢慢地走到了Nginx的路线上，但是我还是应该重申，Apaches能够在支持线程的同时继续运行“事件”免费的主线是有点酷。 一个单一的问题是，这仍然创造了阻塞效应，Apache说：“这个连接正在运行，我不会放弃它的阻塞，直到它完成”，所以它的名字是不是真正的“event-mpm”作为Apache可以仍然受到以下线路中所列的情况的困扰：
生成或检索此页面可能只需几分之一秒，但需要10秒才能将其传输到带宽为80 kbps（10 KB / s）的客户端。
真正上传的问题取决于您上传的内容。 由于我的上传量很大，并且可能会在GB中达到Apache，所以Apache可能会造成问题，但是如果您要上传图片而没有其他更多的function，那么Apache中的更改很有可能发挥作用。
这是相当多的总结。