基于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服务器，网站的整体性能会有一个质的提升。
以上就是基于web应用的性能分析及优化案例，谢谢阅读，希望能帮到大家，请继续关注，我们会努力分享更多优秀的文章。