一个工作进程在网络流量上从不阻塞，等待它的“对手”(客户端)做出反应。当它下了一步，工作进程立即继续其他的游戏，在那里工作进程正在处理下一步，或者在门口欢迎一个新玩家。
为什么这个比阻塞式多进程架构更快？NGINX 每个工作进程很好的扩展支撑了成百上千的连接。每个连接在工作进程中创建另外一个文件描述符和消耗一小部分额外内存。每个连接有很少的额外开销。NGINX 进程可以固定在某个 CPU 上。上下文交换非常罕见，一般只发生在没有工作要做时。
在阻塞方式，每个进程一个连接的方法中，每个连接需要大量额外的资源和开销，并且上下文切换（从一个进程切换到另一个）非常频繁。
更详细的解释，看看这篇关于 NGINX 架构的文章，它由NGINX公司开发副总裁及共同创始人 Andrew Alexeev 写的。
通过适当的系统优化，NGINX 的每个工作进程可以扩展来处理成千上万的并发 HTTP 连接，并能脸不红心不跳的承受峰值流量(大量涌入的新“游戏”)。
更新配置和升级 NGINXNGINX 的进程体系架构使用少量的工作进程，有助于有效的更新配置文件甚至 NGINX 程序本身。
更新 NGINX 配置文件是非常简单、轻量、可靠的操作。典型的就是运行命令 nginx –s reload，所做的就是检查磁盘上的配置并发送 SIGHUP 信号给主进程。
当主进程接收到一个 SIGHUP 信号，它会做两件事：
重载配置文件和分支出一组新的工作进程。这些新的工作进程立即开始接受连接和处理流量（使用新的配置设置）
通知旧的工作进程优雅的退出。工作进程停止接受新的连接。当前的 http 请求一旦完成，工作进程就彻底关闭这个连接（那就是，没有残存的“保持”连接）。一旦所有连接关闭，这个工作进程就退出。
这个重载过程能引发一个 CPU 和内存使用的小峰值，但是跟活动连接加载的资源相比它一般不易察觉。每秒钟你可以多次重载配置（很多 NGINX 用户都这么做）。非常罕见的情况下，有很多世代的工作进程等待关闭连接时会发生问题，但即使是那样也很快被解决了。
NGINX 的程序升级过程中拿到了高可用性圣杯 —— 你可以随随时更新这个软件，不会丢失连接，停机，或者中断服务。
程序升级过程类似于平滑重载配置的方法。一个新的 NGINX 主进程与原主进程并行运行，然后他们共享监听套接字。两个进程都是活动的，并且各自的工作进程处理流量。然后你可以通知旧的主进程和它的工作进程优雅的退出。
整个过程的详细描述在 NGINX 管理。
结论深入 NGINX 信息图 提供一个 NGINX 功能实现的高层面概览，但在这简单的解释的背后是超过十年的创新和优化，使得 NGINX 在广泛的硬件上提供尽可能最好的性能同时保持了现代 Web 应用程序所需要的安全性和可靠性。
如果你想阅读更多关于NGINX的优化，查看这些优秀的资源：
CentOS 6.2实战部署Nginx+MySQL+PHP
搭建基于Linux6.3+Nginx1.2+PHP5+MySQL5.5的Web服务器全过程
CentOS 6.3下配置Nginx加载ngx_pagespeed模块