(编辑:jimmy 日期: 2024/12/23 浏览:2)
如果你的Web应用只跑在一台机器上,那要提升其性能非常简单:换一台更快的,多配几个处理器,多加几条内存,磁盘阵列也要高速的。换了以后,这台机器上跑的WordPress服务器、Node.js或Java应用速度都会加快。(要是应用还会访问另一台数据库服务器,那也简单:找两台更快的机器,用更快的网络连起来就行了)
麻烦在于,机器速度并不是问题。很多时候Web应用慢,是因为要在各种任务之间切换,一会儿要处理数千个连接上的用户请求,一会儿要向磁盘读写文件,一会儿又要运行应用的代码,一会儿又要去干别的。应用服务器因此可能出现各种状况,耗尽内存、交换文件,或者让很多请求等待一个硬盘I/O之类的任务。除了升级硬件,其实你还可以选择另外一种完全不同的方法:加一台反向代理服务器,分担上述一些任务。反向代理服务器位于运行应用的机器之前,负责处理来自外网的请求。反向代理服务器直接连到互联网,它与应用服务器通信使用的是快速的内部网络。反向代理服务器可以让应用服务器专注于构建页面,然后交给反向代理向外网发送,而不必理会用户与应用的交互。由于不必等待客户端的响应,应用服务器的运行速度能达到接近最优的水平。
增加反向代理服务器同时也可以为Web服务器增添灵活性。比如,假设执行某种任务的服务器过载了,那随时可以再增加一台同类服务器;而如果这台服务器挂了,替换它也很容易。鉴于这种灵活性,反向代理服务器往往也是其他性能优化手段的先决条件,比如:
NGINX专门为使用反向代理服务器做了设计,使其天然支持上述优化。由于使用事件驱动的处理机制,NGINX比传统服务器效率更高。NGINX Plus则增加了更高端的反向代理功能,如应用体检、特有的请求路由、高级缓存和售后支持。
建议二:增加负载均衡服务器
增加负载均衡服务器相对简单,但却能显著提升站点性能和安全性。通过它把流量分配给多个服务器,就可以不必升级Web服务器了。就算应用本身写得不太好,或者难以扩展,负载均衡都可以在不做其他改变的情况下提升用户体验。
负载均衡服务器首先是一个反向代理服务器(参见“建议一”),负责把来自互联网的请求转发给其他服务器。这里关键在于负载均衡服务器可以支持两台以上的应用服务器,使用一种选择算法在不同的服务器间分配请求。最简单的负载均衡算法是循环调度,即把新请求依次转发给可用服务器中的下一台服务器。其他算法还有把请求发给活动连接最少的服务器。NGINX Plus支持一种功能,就是把用户会话保持在同一台服务器上,叫做会话保持。负载均衡服务器可以避免一台服务器过载而其他服务器过闲,从而极大提升性能。同时,有了它还可以让Web服务器扩容更简单,因为可以选用比较便宜的服务器,同时保证物尽其用。可以通过负载均衡调度的协议包括HTTP、HTTPS、SPDY、HTTP/2、WebSocket、FastCGI、SCGI、uwsgi、memcached,以及其他一些应用形式,包括基于TCP的应用和其他第四层的协议。为此,首先要分析Web应用,看性能短板在哪里,然后再确定使用哪一个。同一台服务器或用于负载均衡的服务器也可以承担其他任务,比如SSL终止、视客户端不同支持HTTP/1/x或HTTP/2、缓存静态文件。NGINX经常被用来做负载均衡,更多信息请参考我们以前发的介绍性文章、有关配置的文章、电子书和相关的在线视频,当然还有文档。我们的商业版本NGINX Plus支持更多的负载均衡功能,如基于服务器响应时间路由负载和支持微软NTLM协议的负载均衡。
建议三:缓存静态及动态内容
缓存能提升Web应用性能,因为可以更快地把内容交付给客户端。缓存的策略包括预处理内容、在较快的设备上存储内容、把内容保存在靠近客户端的地方,以及同时运用这些策略。缓存有两种。
假设一个页面每秒被查看10次,而你缓存它1秒,那么90%针对这个页面的请求都将来自在缓存。如果你单独缓存静态内容,那么即使全新生成的页面,很可能大部分都来自缓存的内容。缓存Web应用生成内容的技术主要分三种。
Web应用的缓存可以在Web应用服务器内部或外部实现。首先,考虑缓存动态内容,以减轻应用服务器的负载。其次,缓存用于静态内容(包括那些动态生成内容的临时副本),进一步减轻应用服务器的负担。然后,考虑把缓存转移到其他更快或更靠近用户的机器,给应用服务器减负,缩短传输时间。用好缓存能显著加快应用的响应速度。对很多网页来说,大图片之类的静态数据,往往占据一半以上的内容。不用缓存,查询和传输这类数据可能会花好几秒钟,而用缓存,则可能只要花几分之一秒。可以举一个例子来说明怎么使用缓存,NGINX和NGINX Plus通过两个指令来设置缓存:proxy_cache_path和proxy_cache指定缓存的位置和大小、最长缓存时间以及其他参数。使用第三个(也是很受欢迎的)指令proxy_cache_use_stale,甚至可以告诉缓存在本来应该提供新鲜内容的服务器太忙或宕机时,提供原来的旧文件,对客户端来说,拿到内容总比拿不到强。从用户角度看,这样也可以树立你的站点或应用非常稳定的形象。NGINX Plus支持高级缓存功能,包括缓存净化(caching purging)和通过控制板以可视化的形式展示缓存状态,实现实时监控。要了解NGINX中关于缓存的更多信息,可以看看参考文档和NGINX Plus Admin Guide中的NGINX Content Caching。注意: 缓存涉及开发、决策和运维,完善的缓存策略,比如本文提到的这些,能够体现从DevOps角度考虑的价值。也说是说,开发人员、架构师、运维人员此时携手,共同保障一个网站的功能、响应时间、安全和业务目标。
建议四:压缩数据
压缩同样能极大提升性能。图片、视频、音乐等文件都有非常成熟和高效的压缩标准(JPEG和PNG、MPEG-4、MP3),任何一个标准都可以把文件大小缩小一个数量级甚至更多。
文本文件,包括HTML(纯文本和HTML标签)、CSS和JavaScript代码,经常在不压缩的情况下传输。压缩这些数据对提升Web应用的感知性能有时候特别明显,尤其是移动用户的网络很慢又不稳定的情况下。因为文本数据通过对于页面交互能够起到必要的支援作用,而多媒体数据则更多是锦上添花的作用。聪明的内容压缩可以把HTML、JavaScript、CSS等文本内容的缩小30%以上,因此能够相应地减少加载时间。
如果你使用SSL,压缩又可以减少必须经过SSL编码的数据量,从而补偿了压缩这些数据的CPU时间。
压缩数据的方法非常多。比如,建议六中关于HTTP/2的部分就描述了一个新颖的压缩思路,特别适合首部数据压缩。还有一个关于文本压缩的例子,就是可以在NGINX中开启GZIP压缩。预压缩文本数据之后,可以使用gzip_static指令直接发送.gz文件。
建议五:优化SSL/TLS
越来越多的网站在使用Secure Sockets Layer(SSL)及后来的Transport Layer Security(TLS)协议。SSL/TLS通过加密从源服务器发送给用户的数据来提升网站安全性。Google会提升使用SSL/TLS的网站的搜索引擎排名,将有力地推动这一进程。
尽管采用率越来越高,但SSL/TLS造成的性能损失也困扰着很多网站。SSL/TLS拖慢网站的原因有两个。1、每次打开新连接的初次握手都必须创建加密密钥,而浏览器使用HTTP/1.x对每个2、服务器建立多个连接的方式进一步加剧了这个问题。服务器端加密数据和客户端解密数据的操作同样也是开销。为了鼓励人们使用SSL/TLS,HTTP/2和SPDY(参见建议六)的作者将这两个协议设计为只让浏览器针对一次会话建立一个连接。这样就把SSL导致性能降低的两个主要原因之一消灭掉了。然而,说到优化SSL/TLS性能,还是有很多事情可做。优化SSL/TLS的方法因Web服务器而异。以NGINX为例,NGINX使用OpenSSL,运行于普通机器上,能够提供接近定制机器的性能。NGINX SSL performance详细介绍了如何将SSL/TLS加密和解密的开销降至最低。此外,这里还有一篇文章,介绍了很多种提升SSL/TLS性能的方法。简单总结一下,涉及的技术主要有如下几种。
NGINX和NGINX Plus都可以来终止SSL/TLS,即处理客户端信息的加密和解密,同时与其他服务器保持明文通信。在NGINX或NGINX Plus中设置处理SSL/TLS终止可以采取这几个步骤。而对于在接受TCP连接的服务器上使用NGINX Plus而言,可以参考这里的设置步骤。
建议六:实现HTTP/2或SPDY
已经使用SSL/TLS的站点,如果再使用HTTP/2或SPDY则很可能提升性能,因为一个连接只要一次握手。尚未使用SSL/TLS、HTTP/2和SPDY的站点切换到SSL/TLS(通常会降低性能),从响应速度方面看,可能是一次倒退。
谷歌2012年开始SPDY项目,致力于在HTTP/1.x之上实现更快的速度。HTTP/2则是IETF最近批准的基于SPDY的标准。SPDY得到了广泛支持,但很快就将被HTTP/2取代。
SPDY和HTTP/2的关键在于只用一个连接,而非多个连接。这一个连接是多路复用的,因此可以同时承载多个请求和响应。
只维持一个连接,可以省掉多个连接所需的设置和管理消耗。而且一个连接对SSL特别重要,因为可以将SSL/TLS建立安全连接所需的握手时间降至最少。
SPDY协议要求使用SSL/TLS,HTTP/2并没有正式要求,但目前所有支持HTTP/2的浏览器都只会在启用SSL/TLS的情况下才会使用它。换句话说,支持HTTP/2的浏览器只有在网站使用SSL且服务器接受HTTP/2流量的情况下才会使用HTTP/2。否则,浏览器会基于HTTP/1.x通信。
实现了SPDY或HTTP/2之后,域名分片、资源合并、图片精灵等之前针对HTTP的性能优化措施就用不着了。因此也可以简化代码和部署。关于HTTP/2会带来哪些变化,可以参考我们的这个白皮书。
NGINX很早就开始支持SPDY,而且今天使用SPDY的大多数站点都在运行NGIN
X。NGINX同样率先支持了HTTP/2,2015年9月,NGINX开源和NGINX Plus开始支持 HTTP/2。
随着时间推移,NGINX希望大多数站点启用SSL并迁移到HTTP/2。这样不仅可以让网站更安全,而且随着新的优化技术不断涌现,也可以通过简单的代码实现更高的性能。
建议七:升级软件
提升应用性能的一个简单的方法,就是根据可靠性及性能选择软件。此外,高质量组件的开发者更可能不断提升性能和修复问题,因此使用最新的稳定版本是划算。新发布的版本会得到开发者和用户更多的关注,同时也会利用新的编译器优化技术,包括针对新硬件的调优。相对旧版本,新发布的稳定版本明显性能更高。坚持升级,也可以保证在调优、问题修复和安全警报方面与时俱进。不升级软件也会妨碍利用新能力。比如,HTTP/2目前要求OpenSSL 1.0.1。从2016年下半年开始,HTTP/2会要求OpenSSL 1.0.2,该版本发布于2015年1月。NGINX用户可以从NGINX开源软件的最新版本或NGINX Plus开始,它们支持套接字共享、线程池(参见下文),而且都会持续优化性能。因此,检查一下自己的软件,尽量把它们升级到最新的版本。
建议八:调优Linux
Linux是今天大多数Web服务器的底层操作系统,作为一切基础设施的基础,Linux对提升性能至关重要。默认情况下,很多Linux系统都比较保守,仅以桌面办公为需求,以占用少量资源为调优目标。对于Web应用而言,为达到性能最佳,肯定需要重新调优。Linux优化因Web服务器而异。以NGINX为例,可以从以下几方面考虑。
存量队列。如果发现有一些连接得不到处理,可以增大net.core.somaxconn,即等待NGINX处理的最大连接数。如果这个连接数限制过小,应该可以看到错误消息,可以逐步提高这个值,直到错误消息不再出现。
建议九:调优Web服务器
无论使用什么Web服务器,都需要针对应用对其调优。以下建议适用于任何Web服务器,但会给出只有NGINX的设置说明。
提示 修改任何操作系统及周边设备的设置时,每次只修改一项,然后测试性能。如果该项修改导致了问题,或者并未提升性能,再改回去。
建议十:监控实时动态以发现问题和瓶颈
保存应用高性能的关键是实时监控应用性能。必须实时监控特定设备及相应Web基础设施中应用的动态。
监控站点活动多数情况下是被动的,它只告诉你发生了什么,至于如何发现和解决问题,则是你自己的事情。
监控可以捕获以下几种问题:1、服务器停机2、服务器不稳,漏处理连接3、服务器出现大面积缓存失效4、服务器发送的内容不对
New Relic或Dynatrace等全局性的性能监控工具,可以帮我们监控远程加载页面的时间,而NGINX则可以帮你监控应用交付这一端。应用的性能数据可以告诉你优化手段什么时候真正给用户带去了不同的体验,以及什么时候需要扩容以满足越来越多的流量。
为了帮助用户尽快发现问题,NGINX Plus增加了应用程序体检功能,会报告经常重复出现的问题。NGINX Plus还具备session draining特性,会在已有任务完成前阻止新连接,以及慢启动容量,从而让恢复的服务器在负载均衡集群中达到应有的速度。使用得当的情况下,健康体检会在问题显著影响用户体验之前帮你定位问题,而session draining和慢启动则让你替换服务器时不影响感知的性能和在线时间。这张图展示了NGINX Plus内置的实时活动监控的控制板,涵盖了服务器、TCP连接和缓存。
结论:10倍性能提升
性能提升因Web应用不同会有巨大差异。实际的提升取决于预算、时间,以及现有实现的与理想性能的差距。那么怎么让你的应用获得10倍的性能提升呢?为了帮大家理解每项优化建议的潜能,下面再针对之前的建议给出一些实施方针,希望大家各取所需。
以上就是提升Nginx性能的一些建议的详细内容,更多关于提升Nginx性能的资料请关注其它相关文章!