其实也有很多人一直还在使用Nginx_php这种组合搭配，对于Nginx_lua组合的优势在哪里呢?清无介绍说，Nginx+php之间是要有进程之间通信的，这样以来基础的性能开销很大。lua是嵌在Nginx进程内部的，它不需要有两套进程在那里独立工作。所以这块从结构上来说有决定性的优势在里面。再加上线程之间通讯的时候需要大量的反序列化和序列化的工作，然后两套进程带来额外情况是更多的进程更多的切换开销，所以单机上面 Nginx_php要比Nginx_lua要低很多。但是相对来说仍然要回到我们做什么事情上面，因为Nginx_lua目前大的劣势是周边的模块相当的不健全，我们需要大量的时间来积累这些模块。php积累了十几年的时间了，如果说你对性能的要求并不是那么高，我的并发数是几十，那么你用php是合适的。但是如果像一淘数据的数据接口，机器数那么一点，因为我的大量成本在MySQL集群上面，它是这块的主力，那么对外的数据接口我希望尽可能降成本，并发数又非常大，php肯定是不行，那么我们要选择Nginx_lua。但这块的话对模块的劣势看起来不是那么大，因为它的逻辑相对来说较为固定，我们可以忍受这样的成本，我们去为这个逻辑来定制一些模块。

 

 　　从上面的两张性能测试图中我们总结Nginx_lua的适用场景：

　　网络I/O 阻塞时间远高于CPU 计算占用时间、同时上游资源非瓶颈(可伸缩)的网络应用，如高性能网络中间层、HTTP REST 接口服务等;

　　期望简化系统架构，让服务向Nginx 同质化的Web 站点;

 　　Nginx_lua的优势和劣势

　　对于Nginx_lua的劣势在刚刚和Nginx_php的对比的时候清无也介绍了一个是周边模块不完善，不健全的问题。如果你用到的这个东西比较复杂的时候可能生产力上不去，目前Nginx_lua适合的人员是数据接口层，以及所有的网络中间层，你需要求并发，高性能的网络中间层。因为它本身的逻辑相对来说比较简单，或者完全用lua本身可以变现出来，这个用起来收效比例是大的。那么如果你目前要做一个复杂的WEB访问站，有大量模板要套，有大量的复杂逻辑嵌在里面，然后要访问mail要访问其他服务的话，目前来说我觉得还是php或者其他比较成熟的语言。我们目前应用来说也是这样，中间层会大量的使用lua，但是前端展现层的话要么全部移到浏览器上面用JS+模板的形式来实现，要么是用PHP这样来做。

　　另外的劣势是调试的辅助工具不太多，因为高级点的php程序员会往往会使用XDebug或者其它的调试工具，可以单步调试，在线调试。跟php相比目前还欠缺这样的一个机制。到时候我们会仿照XDebug 去实现DPT V2协议，我们实现兼容DPT V2这样的一种机制内连到Nginx_lua里面，那样Nginx_lua也可以单步调试。到时候我们也会分享给大家。