大家好,欢迎来到停止重构的频道。
本期,我们讨论Nginx的性能调优。
Nginx一般是作为网站系统的反向代理或负载均衡,但这里有一个问题,负载均衡可以绑定多个后端服务器。
一个后端服务器宕机后,另外的后端服务器仍可继续运行,那负载均衡(Nginx)本身宕机了呢?在本期的集群方案将讨论这个问题。
我们按这样的顺序介绍
明确目标性能
硬件选择
单个Nginx服务调优
集群方案
明确性能指标
在调优之前需要先明确性能指标, 根据往期《性能指标》 整体系统的性能指标是并发量、吞吐量、错误率、响应时间。
在调试单个服务时,根据往期《调优基本思路》的结论,只需要明确吞吐量即可,如果整个系统的吞吐量指标为1000rps,则Nginx作为负载均衡的话,理论上吞吐量为1000rps即可。
不过,Nginx作为负载均衡的话是整个网站系统的总入口,而且Nginx的最终吞吐量与业务功能、请求返回的数据量是强关联,所以单独测试Nginx性能也没有实际意义。
一般判断Nginx性能是否足够是在整体系统性能测试时,观察Nginx服务器与其他服务器的负载情况,负载情况分析可参考往期《负载分析》。
例如,如果在整体性能测试时,Nginx的负载是满的(如CPU、内存、带宽使用率等),但其他服务的负载是未满的,则说明Nginx服务存在性能瓶颈,这时可以考虑增加增加硬件配置。
如果网站系统是公网公开的话,负载均衡最好选择公有云的负载均衡,因为它们会提供完整的边缘网络方案,也就是说不会拥堵在一个Nginx服务上。
硬件选择
Nginx的硬件选择一般是选择CPU和内存,cpu和内存的配比一般为1:2,当然,内存大小的选择更依赖文件缓存的预期大小,如果没有文件缓存的需要,内存大小可以低一些。
Nginx的硬件配置不需要太高,一般4核CPU的服务即可达到几万RPS。
Nginx服务器的带宽也是需要重点观察的,因为Nginx作为负载均衡的话一般是作为整个网站系统的总入口,所以网络带宽的消耗是很大的。
如果有上传下载文件功能的话,最好把上传下载文件用单独的负载均衡处理,这样就不会因为文件传输影响主体功能。
另外,Nginx除了作为负载均衡、反向代理,还有很多其他功能,如作为代理服务器做网络跳板、rtmp视频流服务器等。
如果有这些功能需要,最好部署单独的Nginx服务,出现性能问题时,能更好地对症下药。
单个Nginx服务调优
接下来是对单个Nginx服务调优,在这之前,需要先调优服务器内核参数,调优方法可以参考往期《内核参数调优》。
单个Nginx服务调优可参考图中所示,另外,Nginx作为前端服务器软件的话,还可以缓存文件以减少磁盘读写,但是如果配置了CDN加速的话,其实缓存文件的意义也不大。
集群方案
严格意义上讲,Nginx是没有集群方案的,但是由于Nginx是无状态,所以可以使用keepalived作为集群方案。
每个服务器都安装keepalived和nginx后,这些服务器会抢占同一个虚IP,当一台服务器宕机,别的服务器会重新占用虚IP并继续接收请求。
虚ip其实就是还没与某个服务器绑定的IP。
这也是解决开篇问题的方案,这也是比较常用的Nginx的高可用方案,但是这个方案也会在一定程度上降低Nginx服务器的性能。
总结
截止本期,我们介绍完了MySQL、Redis、Nginx、Tomcat这些常用软件的性能优化和集群方案。
其实调优思路都是基本雷同的,只要掌握了基本思路,其他软件服务的调优也都是差不多的。
后面几期,我们将介绍一些提高性能的编程方案。