前段时间对某个企业应用网站进行了一次优化分析,解决这个网站经常死机和CPU高负载的种种问题,根据我接触的一些应用和服务器配置,我对这个案例总结了一些优化方案,用来解决网站的高负载和高并发等问题,这里我和大家分享一下这个案例,希望能和大家一起探讨一下这种解决方案的优劣。
一、网站当前状况和性能现状
系统硬件配置:CPU为两个Intel Xeon 2.4G,物理内存为2.5G.
系统软件配置:操作系统为Windows Server 2003标准版,数据库为SQL Server 2000.
服务器访问量:工作日:访问人数 10000,浏览量 30000 ,休息日:访问人数 4000,浏览量 10000,每用户访问页面为2.88页面,平均停留时间为3分钟。由于存在大型下载文件,服务器流量每天有80G到160G左右。
WEB系统:采用Tomcat服务器,使用Struts和Hibernate.
网站系统:网站有几套不同的系统,有新闻发布CMS系统、文件下载系统、反馈系统等等,使用基于Java的Struts和Hibernate的MVC架构,动态应用。
服务器CPU目前通常为40%左右,很多情况能增加到80-90%.
二、网站性能分析
通常情况下CPU达到80%说明系统性能存在瓶颈,需要找出系统的瓶颈究竟在哪里。
分析过程是,远程登录服务器,打开SQL Server 2000的事件探查器,记录和分析SQL语句,同时打开任务管理器,查看各个进程占用CPU的状况。
经过查询,SQLServer占用较大的CPU,说明系统调用CPU查询较多,初步可以确认是数据库引起的系统瓶颈,由于使用Struts和Hibernate应用,调用数据库频繁,因此可以采用减少SQL查询的方式降低对SQLServer的调用,通常情况下有两种方法:Cache或静态化。
另外,服务器的Web系统采用的架构存在一些问题,因为存在大型下载文件,占用的流量非常大,而Tomcat本身对于静态文件的处理性能并不好,也会对系统性能产生负面的影响。
三、网站和服务器优化方案
1、缓存
将页面静态化是通常的优化方案,但是对于当前的Tomcat服务器下的Struts和Hibernate未必有效,因为Tomcat对于静态HTML文件本身支持并不理想,并且新闻内容更新较为频繁。因此,在现有架构的基础上,可以使用hibernate的ehcached的动态缓存的方式,在动态应用中减少数据库负载,提升访问速度。
使用ehcache对访问频率高,对数据库消耗大的页面进行动态缓存(时间10分钟),在缓存的时间范围内这些页面直接重缓存中读取,无需访问数据库,提高这些页面的访问速度,减小数据库访问的压力。这样SQL Server数据库的负载会大为降低。
2、静态化
对于一般的网站来说,效率最高、消耗最小的就是纯静态化的html页面,所以我们尽可能使我们的网站上的页面采用静态页面来实现,这个最简单的方法其实也是最有效的方法。因此,从长远考虑,需要对当前网站的架构进行一番调整,以适应静态化页面的需求。
首先,由于Tomcat对于静态页面支持不太好,也不支持URL 重写,因此需要安装Apache服务器。
其次,由于Struts对于搜索引擎不友好,因此将其全部转换为静态HTML页面,即可降低对数据库的查询次数,也可提高对搜索引擎的友好度。因此需要使用HTML静态化的方式优化服务器端的WEB程序。
具体实施方案是,将现有Tomcat配置为8080端口,安装Apache服务器,配置为80端口,在Apache中修改httpd.conf文件,使得Tomcat解析JSP文件,静态HTML文件、图片文件、大型下载文件使用性能更好的Apache支持。
修改Apache的.haccess文件,将Struts应用重写为静态Html文件形式,修改相关代码,使得其能自动生成静态HTML文件。
优化访问量最多的页面,首页index.jsp为目前访问量最多的页面,里面的动态代码删除,将这个页面转化为静态的html页面index.html.
3、应用部署
如果资金允许的话,可以将数据库SQL Server 2000升级为SQLServer 2005,并单独部署到另外一台独立服务器上,文件下载也单独部署一台服务器。
由于Tomcat本身的局限性,一个Tomcat的资源无法无限利用服务器的所有资源,并且Tomcat需要响应的请求太多,势必影响到整体的性能,因此配置多服务器可以使得Web网站的负载大幅降低,从而提高整体的响应能力。
不过这种部署的缺点是需要付出升级软件、购买服务器、托管带宽等成本开销,建议不到万不得已,可以不用付出额外的资金升级。
以上就是我针对某企业应用网站进行分析和优化的具体步骤和方案,希望能起到抛砖引玉的作用,供大家参考。
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/netbug2009/archive/2010/07/22/5755983.aspx