文/任世宗 李润知 张茜 王宗敏
基于Nginx的可扩展负载均衡Web站点部署
文/任世宗 李润知 张茜 王宗敏
随着网络服务的日趋完善,我们在获得方便的同时,也面临着巨大的挑战:并发业务访问数量的直线增长,是网络中的Web服务器工作能力的严峻考验。
采用多服务器集群技术是解决上述问题的有效方案,而负载均衡是集群技术的核心问题。负载均衡能够将大量的并发访问请求合理地均分到集群内的各服务器上进行处理,有效地避免了单一服务器数据流过大的问题,同时能够使各个服务器的资源得到均衡的使用。负载均衡包括硬件和软件两种类型,硬件的成本高昂,软件的负载均衡配置部署灵活,越来越受到人们的亲睐。
Nginx是中小企业软件负载均衡的不错选择。Nginx支持高并发,官方测试可支持5万的并发连接。进程消耗内存少,每个Nginx进程仅消耗十几兆的内存。Nginx作为开源软件,成本低廉。另外,Nginx配置文件简单,稳定性高,且非常易于部署。但是Nginx也存在一些问题:它作为反向代理服务器时,连接的后端物理Web应用服务器(如Apache、IIS等)性能无法得到充分利用,不易于根据业务并发量动态的调整后端服务器的数量,负载均衡的效果不是特别理想。
本文提出了用Nginx反向代理虚拟机的方式实现Web站点的负载均衡,既充分的利用了CPU、内存等硬件资源,又满足了高并发的需求,并且具有非常好的扩展性。
如图1所示,我们对服务A启用A1、A2两台虚拟机,部署到两台不同的物理机上,对服务B做类似的部署。这样,既避免了由于物理机故障,导致服务中断,又有效地利用了物理机的资源。
在采用此种架构的基础上,我们对Nginx的主配置文件nginx.conf进行一些优化:
user www www;
#只开启一个进程,节省内存
work_processes 1;
error_log /usr/local/nginx/nginx_error.log crit;
pid /usr/local/nginx/nginx.pid;
work_rlimit_nofile51200;
events
{
use epoll;
work_connections 51200; }
http
{
include /user/local/nginx/mime.types; default_type application/octet-stream; #charset utf-8
server_names_hash_bucket_size 128; client_header_buffer_size 32k;
large_client_header_buffers 4 64k;
#指定 nginx 是否调用 sendfile 函数(zero copy 方式)来输出文件,对于普通应用,
必须设为 on,如果用来进行下载等应用磁盘
IO重负载应用,可设置为 off,以平衡磁盘与网络I/O处理速度,降低系统的uptime
sendfile on;
#tcp_nopush和tcp_nodely两个指令设置为on,用于防止网络阻塞
tcp_nopush on tcp_nodelay on; keepalive_timeout 65;
#对网页文件、CSS、JS、XML等启动gzip压缩,减少数据传输量,提高访问速度。
gzip on;
gzip_min_length 1k; gzip_buffers 4 8k;
gzip_http_version 1.1; gzip_comp_level 3;
gzip_typestext/plain application/x-javascripts test/ css application/xml;
gzip_vary on;
#设定负载均衡服务器列表,采用ip hash的方式进行负载均衡,使来自同一个ip的访客固定访问一个后端服务器,有效解决session共享问题。
upstream myserver {
ip_hash;
server 192.168.100.1∶80 weight=5 max_fails=2 fail_ timeout=30s;
server 192.168.100.2∶80 weight=5 max_fails=2 fail_ timeout=30s;
}
server
{
listen80;
server_namewww.youdomain.com;
root www/myserver
location/
{
proxy_next_upstream http_502 http_504 error timeout invalid_header;
proxy_pass http∶//myserver;
proxy_set_header Host www.youdomain.com;
proxy_set_header X-Forward-For $remote_addr; }
#将动态的页面交给后端的Web服务器群组处理。
location ~ .*.(php|jsp|cgi)?$
{
proxy_set_header Host www.youdomain.com;
proxy_set_header X-Forward-For $remote_addr; proxy_pass http∶//myserver;
#将动静页面进行分离,定义静态资源由Nginx发布目录读取。
location ~ .*.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|j s|css)$
{
root /www/myserver;
# 图片、静态页等不常更改,设置它们在用户浏览器的本地缓存为3天,提高访问速度
图1 实现Web站点的负载均衡
expires 3d;
access_log /logs/www.youdomain.com_access.log; }足这种动态的业务需求,随时的增加、减少虚拟机,非常方便。
1.利用Nginx进行动静分离,充分发挥Nginx处理静态页的优势,有效减轻后端虚拟机的负载。
2.通过ip hash实现后端虚拟机的负载均衡,保证来自同一ip的访问请求定位在一个虚拟机上,有效解决session共享问题。
3.通过gzip压缩、用户浏览器缓存等的设置,节省带宽,提高访问速度。
4.传统的IIS、Apache服务器等在并发连接高的时候,很容易崩溃。利用本文提出的架构可以有效地将并发连接均分到多个虚拟机,这样每个虚拟机的并发连接数在相对较低的情况下,减小了崩溃的可能性。
5.软件依赖于硬件,因此计算机硬件的更新速度始终快于软件。考虑到IIS、Apache等的并发瓶颈问题,如果我们的服务器仅仅作为一个Web服务器的话,其性能很难得到充分的发挥,资源利用率并不高。采用虚拟机的方式可以充分的利用系统资源,借助于Nginx最为反向代理,在低成本投入的前提下,实现高并发、高性能的Web服务。
6.随着企业业务的发展,用户的数量可能会不断增加;另外,某些企业也可能在不同的时间段内有差别很大的访问量。用Nginx反向代理虚拟机的形式可以很好的满
工具介绍
本次测试采用的软件是LoadRunner。
LoadRunner是一种适用于各种体系架构的自动化负载测试工具,它通过模拟大量实际用户的操作行为,对被测试系统实施并发负载测试,同时对被测试的系统进行实时的性能监测,并自动整理生成测试结果,以便于找出性能的瓶颈。它主要由六部分组成:
1.虚拟用户生成器(Vugen):追踪业务和生成测试脚本
2.压力生成器:模拟真实用户产生负载。
3.用户代理:调整整个虚拟用户,使步调一致。
4.压力调度:跟踪用户需求,改变虚拟用户数量。
5.监控系统:监控性能指标。
6.测试结果分析器:生成各种分析图表,用于分析瓶颈。
性能指标
本次测试主要选取了并发用户、响应时间、系统资源利用率三个比较具有代表性的参数进行记录分析。
1.并发用户
指所有用户在同一时刻做同一事情或操作,这种操作一般针对通一类型的业务;或者所有用户进行完全一样的操作,目的是测试程序对并发操作的处理。
2.响应时间
响应时间是从用户的角度分析的时间延迟,单位为毫秒或秒。作为最终用户来说,评价系统性能的好坏只能根据感觉时间的快慢,他不关心并发访问系统的人数等其他因素。Web应用系统的性能,可以认为是系统的平均响应时间。通常情况下,系统负载能力越大,响应时间越短。访问的用户数越大,响应时间越长。
3.资源利用率
资源利用率是只对不同系统资源的使用程度,是测试和分析瓶颈,改善系统性能的主要依据。
图2
图3
图4
图5
图6
图7
图8
本次测试的对象是某高校的研究生院网站,它的逻辑并不复杂,但在每年的招生期间有很高的并发量。首先,单台物理机下进行测试;然后,搭建Nginx反向代理服务器,再次进行测试;最后,对Nginx进行优化后的测试。
三次测试的过程中均录制统一的脚本,设置初始用户100,每次增加50的并发用户。
1.单台物理机搭建LLS服务器性能测试
测试环境:Xeon 4核处理器+4G内存+Windows Server 2003+IIS6.0
测试分析:
(1)并发用户
当并发用户到达200的时候开始出现错误,随着虚拟用户的继续增长,大部分访问请求都不能pass,打开浏览器发现网站页面打不开,如图2所示。
(2)系统平均响应时间
我们发现随着并发访问数量的增加,系统的响应时间直线增长,系统的平均响应时间很高,最高超过100秒,如图3所示。
(3)系统资源
我们可以看到随着虚拟用户的增长,CPU资源的占用率没有明显增长的趋势,内存空闲资源仅稍有减少,如图4所示。
通过对结果的分析,我们看到,LLS服务器在虚拟用户数达到将近200的时候开始出错,300的时候已经崩溃,而系统的资源利用率实际上并不高。
2.利用Nginx反向代理虚拟机时的性能测试
测试环境:2台单核2G的虚拟机(Windows Server 2003+IIS6.0)+双核4G的Nginx物理机。
测试分析:
(1)并发用户
当并发用户到达550的时候开始出现错误,部分访问请求不能pass,打开浏览器发现网站页面打开极慢,如图5所示。
(2)系统平均响应时间
我们看到,使用Nginx进行反向代理之后,系统的响应时间有所降低,最高50秒左右,但是还是很高,可能与测试环境有关,如图6所示。
(3)系统资源
Loadrunner只能监测到Nginx服务器的系统资源,我们在测试的过程中通过登录IIS服务器发现CPU资源利用率在平均约45%,内存利用率平均约50%,都没有随并发连接数急剧增长的现象。
通过对结果的分析,我们看到,通过Nginx反向代理IIS虚拟机,有效的提升了网站并发访问的负载能力,IIS虚拟机的资源利用率比单个物理机时更充分。
3.对Nginx进行优化后的性能测试
测试环境:2台单核2G的虚拟机(Windows Server 2003+IIS6.0)+双核4G的Nginx物理机(优化后的)。
测试分析:
(1)并发用户
我们发现,经过对Nginx的优化,当并发用户到达650的时候才开始出现第一个错误,随着虚拟用户的增加,错误数量的增加不是太快,打开浏览器发现网站页面还能打开,只是访问速度慢,说明Nginx服务器和IIS服务器均没有崩溃,如图7所示。
(2)系统平均响应时间
从图表中我们看到,响应时间和对Nginx进行优化前对比有显著减少,平均在12秒左右,最高24秒,如图8所示。
(3)系统资源
同样通过直接登录查看IIS虚拟机的系统资源,发现CPU利用率平均约45%,内存利用率平均约50%,跟优化前没有明显区别。
通过对结果的分析,我们看到,对Nginx的合理优化有效的增加了并发访问量,减少了系统响应时间,进一步提高了Web服务的性能,系统资源的利用率保持不变。
Nginx是一款不错的反向代理软件,利用Nginx反向代理虚拟机的架构可以有效避免IIS、Apache的并发瓶颈问题,并且增加了网站的可扩展性。通过对高校网站的压力测试,证实了Nginx反向代理虚拟机架构的可用性,同时发现了网站的瓶颈所在。总的来说,Web应用的性能是受多方面影响的,不能一味去增加硬件设备,要通过实际的测试,找出瓶颈所在,多从优化架构、优化参数配置入手,从而提高性能,提高Web服务的质量。
(作者单位为郑州大学信息网络重点开放实验室)