基于Web应用的性能分析及优化案例

一、 基于动态内容为主的网站优化案例

1.网站运行环境说明
硬件环境:1台IBM x3850服务器, 单个双核Xeon 3.0G CPU,2GB内存,3块72GB SCSI磁盘。
操作系统:CentOS5.4。
网站架构:Web应用是基于LAMP架构,所有服务都在一台服务器上部署。
2.性能问题现象及处理措施
   现象描述
网站在上午10点左右和下午3点左右访问高峰时,网页无法打开,重启服务后,网站能在一段时间内能正常服务,但过一会又变得响应缓慢,最后网页彻底无法打开。
   检查配置
首先检查系统资源状态,发现服务出现故障时系统负载极高,内存基本耗尽,接着检查Apache配置文件httpd.conf,发现“MaxClients”选项值被设置为2000,并且打开了Apache的KeepAlive特性。
   处理措施
根据上面的检查,初步判断是Apache的”MaxClients“选项配置不当引起的,因为系统内存仅有2GB大小,而“MaxClients”选项被配置为2000,过多的用户访问进程耗尽了系统内存;然后,修改httpd.conf配置文件的“MaxClients”选项,将此值由2000降到1500;继续观察发现,网站还是频繁宕机,于是又将“MaxClients”选项值降到1024,观察一段时间发现,网站服务宕机时间间隔加长了,不像以前那么频繁,但是系统负载还是很高,网页访问速度极慢。
3.第一次分析优化
   既然是由系统资源耗尽导致的网站服务失去响应,那么就深入分析系统资源的使用情况,通过uptime、vmstat、top、ps等命令的联合使用,得出如下结论:
   结论描述
系统平均负载很高,通过uptime输出的系统“load average”值都在10以上,而CPU资源也消耗严重,这是造成网站响应缓慢或长时间没有响应的主要原因,而导致系统资源消耗过高的主要依据是用户进程消耗资源严重。
   原因分析
通过top命令发现,每个Apache子进程消耗将近6~8MB左右内存,这是不正常的。根据经验,在正常情况下每个Apache子进程消耗的内存在1MB左右,结合Apache输出日志发现,网站首页访问频率最高,也就是说首页程序代码可能存在问题。于是检查首页的PHP代码,发现首页的页面非常大,图片很多,并且由全动态的程序组成,这样每次用户访问首页都要多次查询数据库,而查询数据库是个非常耗费CPU资源的过程,并且首页PHP代码也没有相应的缓存机制,每个用户请求都要重新进行数据库查询操作,数据库查询负荷有多高可想而知。
   处理措施
修改首页PHP代码,缩减页面大小,并且对访问频繁的操作增加缓存机制,尽量减少程序对数据库的访问。
4.第二次分析优化
   通过前面简单优化,系统服务宕机现象出现次数减少很多,但是在访问高峰时网站偶尔还会无法正常访问。这次仍然从分析系统资源使用状况入手,发现系统内存资源消耗过大,并且磁盘I/O有等待问题,于是得出如下结论:
   原因分析
内存消耗过大,肯定是用户访问进程数过多导致的,在没有优化PHP代码之前,每个Apache子进程消耗6~8MB内存,如果设置Apache的最大用户数为1024,那么内存耗尽是必然的,当物理内存耗尽时,虚拟内存就会启用,频繁地使用虚拟内存,肯定会出现磁盘I/O等待问题,最终导致CPU资源耗尽。
   处理措施
通过上面对PHP代码的优化,每个Apache子进程消耗的内存资源基本维持在1~2MB左右,因此修改Apache配置文件httpd.conf中的”MaxClients”选项值为“600”,同时把Apache配置中的“KeepAlive”特性关闭,这样Apache进程数大量减少,基本维持在500~600之间,虽然偶尔也会使用虚拟内存,但是Web服务正常了,服务宕机问题也很少出现了。
5.第三次分析优化
经过前两次的优化,网站基本运行正常,但是在访问高峰时偶尔还会出现站点无法访问得现象,继续进行问题分析,通过命令查看系统资源,发现仍是CPU资源耗尽导致的,但是与前两次又有所不同:
   原因分析
通过观察后台日志,发现PHP程序有频繁访问数据库的操作,大量的SQL语句中有where, order by等子句;同时,数据库查询过多,大部分都是复杂查询,一般都需要遍历全表,而大量的表没有建立索引,这样的程序代码导致MySQL数据库负荷过高,而MySQL数据库和Apache部署在同一台服务器上,这也是导致服务器消耗CPU资源过高的原因。
   处理措施
优化程序中的SQL语句,增加where子句上的匹配条件,减少遍历全部的查询,同时在where和order by子句的字段上建立索引,并且增加程序缓存机制,通过这次优化,网站运行基本处于正常状态,再也没有出现宕机的现象。

6.第四次优化分析
通过前面三次优化以后,网站在程序代码、操作系统、Apache等方面的优化空间越来越小,要避免出现服务气宕机现象,并且保证网站稳定、高效、快速地运行,可以从网站结构上进行优化,也就是将Web和数据库分离部署,可以增加一台专用的数据库服务器,单独部署MySQL数据库。随着访问量的增加,如果前端无法满足访问请求,还可以增加多台Web服务器,Web服务器之间进行负载均衡部署,解决前端性能瓶颈;如果在数据库端还存在读写压力,还可以继续增加一台MySQL服务器,将MySQL进行读写分离部署,这样一套高性能、高可靠的网站系统就构建起来了。

二、  基于动态、静态内容结合的网站优化案例

1.网站运行环境说明
硬件环境:两台IBM x3850服务器, 单个双核Xeon 3.0G CPU,4GB内存,3块72GB SCSI磁盘。
操作系统:CentOS5.4。
网站架构:Web应用是基于J2EE架构的电子商务应用,Web端应用服务器是Tomcat,采用MySQL数据库,Web和数据库独立部署在两台服务器上。

2.性能问题现象以及处理措施
   现象描述
网站访问高峰时,网页无法打开,重启Java服务后,网站可以正常运行一段时间,但过一会又变得响应缓慢,最后网页彻底无法打开。
   检查配置
首先检查系统资源状态,发现服务出现故障时系统负载极高,CPU满负荷运行,Java进程占用了系统99%的CPU资源,但内存资源占用不大;接着检查应用服务器信息,发现只有一个Tomcat在运行Java程序;接着查看Tomcat配置文件server.xml,发现server.xml文件中的参数都是默认配置,没有进行任何优化。
   处理措施
server.xml文件的默认参数需要根据应用的特性进行适当的修改,例如可以修改“connectionTimeout“、“maxKeepAliveRequests”、“maxProcessors”等几个Tmcat配置文件的参数,适当加大这几个参数值。修改参数值后,继续观察发现,网站服务宕机时间间隔加长了,不像以前那么频繁,但是Java进程消耗CPU资源还是很严重,网页访问速度极慢。

3.第一次分析优化
既然Java进程消耗CPU资源严重,那么需要查看到底是什么导致Java消耗资源严重,通过lsof、netstat命令发现有大量的Java请求等待信息,然后查看Tomcat日志,发现大量报错信息、日志提示和数据库连接超时,最终无法连接到数据库,同时,访问网站静态资源,也无法访问,于是得出如下结论:
   原因分析
Tomcat本身就是一个Java容器,是使用连接/线程模型处理业务请求的,主要用于处理Jsp、servlet等动态应用,虽然它也能当作HTTP服务器,但是处理静态资源的效率很低,远远比不上Apache或Nginx。从前面观察到的现象分析,可以初步判断是Tomcat无法及时响应客户端的请求,进而导致请求队列越来越多,直到Tomcat彻底崩溃。对于一个正常的访问请求来说,服务器接收到请求后,会把请求交给Tomcat去处理,Tomcat接着执行编译、访问数据库等操作,然后把信息返回给客户端,客户端接收到信息后,Tomcat就关闭这个请求链接,这样一个完整的访问过程就结束了。而在高并发访问状态下,很多的请求瞬间都交给Tomcat处理,这样Tomcat还没有完成第一个请求,第二个请求就来了,接着是第三个,等等,这样越积越多,Tomcat最终失去响应, Java进程就会处于僵死状态,资源无法释放,这就是根本原因。
   处理措施
要优化Tomcat性能,需要从结构上进行重构,首先,加入Apache支持,由Apache处理静态资源,由Tomcat处理动态请求,Apache服务器和Tomcat服务器之间使用Mod_JK模块进行通信。使用Mod_JK模块的好处是:它可以定义详细的资源处理规则,根据动态、静态网站的特点,将静态资源文件全部交给Apache处理,而动态请求通过Mod_JK模块传给Tomcat去处理,通过Apache+JK+Tomcat的整合,可以大幅度提高Tomcat应用的性能。

4.第二次分析优化
经过前面的优化措施,Java资源偶尔会增高,但是一段时间后又会自动降低,这属于正常状态,而在高并发访问情况下,Java进程有时还会出现资源上升无法下降的情况,通过查看Tomcat日志,综合分析得出如下结论:
要获得更高、更稳定的性能,单一的Tomcat应用服务器有时会无法满足需求,因此要结合Mod_JK模块运行基于Tomcat的负载均衡系统,这样前端由Apache负责用户请求的调度,后端又多个Tomcat负责动态应用的解析操作,通过将负载均分配给多个Tomcat服务器,网站的整体性能会有一个质的提升。

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。