网站被域名重定向,通化工程建设信息网站,响应式mvc企业网站源码,音乐网站开发需要什么语言工具一、Nginx性能优化 到这里文章的篇幅较长了#xff0c;最后再来聊一下关于Nginx的性能优化#xff0c;主要就简单说说收益最高的几个优化项#xff0c;在这块就不再展开叙述了#xff0c;毕竟影响性能都有多方面原因导致的#xff0c;比如网络、服务器硬件、操作系统、后端…一、Nginx性能优化 到这里文章的篇幅较长了最后再来聊一下关于Nginx的性能优化主要就简单说说收益最高的几个优化项在这块就不再展开叙述了毕竟影响性能都有多方面原因导致的比如网络、服务器硬件、操作系统、后端服务、程序自身、数据库服务等对于性能调优比较感兴趣的可以参考之前《JVM性能调优》中的调优思想。
优化一打开长连接配置 通常Nginx作为代理服务负责分发客户端的请求那么建议开启HTTP长连接用户减少握手的次数降低服务器损耗具体如下
upstream xxx {# 长连接数keepalive 32;# 每个长连接提供的最大请求数keepalived_requests 100;# 每个长连接没有新的请求时保持的最长时间keepalive_timeout 60s;
}优化二、开启零拷贝技术 零拷贝这个概念在大多数性能较为不错的中间件中都有出现例如Kafka、Netty等而Nginx中也可以配置数据零拷贝技术如下 sendfile on; # 开启零拷贝机制零拷贝读取机制与传统资源读取机制的区别
传统方式硬件--内核--用户空间--程序空间--程序内核空间--网络套接字零拷贝方式硬件--内核--程序内核空间--网络套接字
从上述这个过程对比很轻易就能看出两者之间的性能区别。 优化三、开启无延迟或多包共发机制 在Nginx中有两个较为关键的性能参数即tcp_nodelay、tcp_nopush开启方式如下 tcp_nodelay on;
tcp_nopush on;TCP/IP协议中默认是采用了Nagle算法的即在网络数据传输过程中每个数据报文并不会立马发送出去而是会等待一段时间将后面的几个数据包一起组合成一个数据报文发送但这个算法虽然提高了网络吞吐量但是实时性却降低了。 因此你的项目属于交互性很强的应用那么可以手动开启tcp_nodelay配置让应用程序向内核递交的每个数据包都会立即发送出去。但这样会产生大量的TCP报文头增加很大的网络开销。 相反有些项目的业务对数据的实时性要求并不高追求的则是更高的吞吐那么则可以开启tcp_nopush配置项这个配置就类似于“塞子”的意思首先将连接塞住使得数据先不发出去等到拔去塞子后再发出去。设置该选项后内核会尽量把小数据包拼接成一个大的数据包一个MTU再发送出去. 当然若一定时间后一般为200ms内核仍然没有积累到一个MTU的量时也必须发送现有的数据否则会一直阻塞。 tcp_nodelay、tcp_nopush两个参数是“互斥”的如果追求响应速度的应用推荐开启tcp_nodelay参数如IM、金融等类型的项目。如果追求吞吐量的应用则建议开启tcp_nopush参数如调度系统、报表系统等。 注意 ①tcp_nodelay一般要建立在开启了长连接模式的情况下使用。 ②tcp_nopush参数是必须要开启sendfile参数才可使用的。 优化四、调整Worker工作进程 Nginx启动后默认只会开启一个Worker工作进程处理客户端请求而我们可以根据机器的CPU核数开启对应数量的工作进程以此来提升整体的并发量支持如下 # 自动根据CPU核心数调整Worker进程数量
worker_processes auto;工作进程的数量最高开到8个就OK了8个之后就不会有再大的性能提升。 同时也可以稍微调整一下每个工作进程能够打开的文件句柄数 # 每个Worker能打开的文件描述符最少调整至1W以上负荷较高建议2-3W
worker_rlimit_nofile 20000;操作系统内核kernel都是利用文件描述符来访问文件无论是打开、新建、读取、写入文件时都需要使用文件描述符来指定待操作的文件因此该值越大代表一个进程能够操作的文件越多但不能超出内核限制最多建议3.8W左右为上限。 优化五、开启CPU亲和机制 对于并发编程较为熟悉的伙伴都知道因为进程/线程数往往都会远超出系统CPU的核心数因为操作系统执行的原理本质上是采用时间片切换机制也就是一个CPU核心会在多个进程之间不断频繁切换造成很大的性能损耗。
而CPU亲和机制则是指将每个Nginx的工作进程绑定在固定的CPU核心上从而减小CPU切换带来的时间开销和资源损耗开启方式如下 worker_cpu_affinity auto;优化六、开启epoll模型及调整并发连接数 在最开始就提到过Nginx、Redis都是基于多路复用模型去实现的程序但最初版的多路复用模型select/poll最大只能监听1024个连接而epoll则属于select/poll接口的增强版因此采用该模型能够大程度上提升单个Worker的性能如下 events {# 使用epoll网络模型use epoll;# 调整每个Worker能够处理的连接数上限worker_connections 10240;
}这里对于select/poll/epoll模型就不展开细说了后面的IO模型文章中会详细剖析。 二、放在最后的结尾 至此Nginx的大部分内容都已阐述完毕关于最后一小节的性能优化内容其实在前面就谈到的动静分离、分配缓冲区、资源缓存、防盗链、资源压缩等内容也都可归纳为性能优化的方案。
