企业应用网站性能优化实例分析

前段时间对某个企业应用网站进行了一次优化分析，解决这个网站经常死机和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

企业应用网站性能优化实例分析相关推荐

企业应用网站性能优化实例分析_SEO的关键
前段时间对某个企业应用网站进行了一次优化分析,解决这个网站经常死机和CPU高负载的种种问题,根据我接触的一些应用和服务器配置,我对这个案例总结了一些优化方案,用来解决网站的高负载和高并发等问题,这里我 ...
大型网站性能监测、分析与优化常见问题QA
@tanwen110 (唐文),曾负责腾讯四大平台之一网络媒体平台的整体运维.运营规划工作:曾任百度T7架构师和百度性能优化TOPIC.百度UAQ.APM平台负责人:畅销书<海量运维.运营规划之 ...
炫技，从12.67s到1.06s的网站性能优化实战
(给视学算法加星标,提升全栈技能) 作者:jerryOnlyZRJ https://juejin.im/post/5b6fa8c86fb9a0099910ac91 0.引言作为互联网项目,最重要的便 ...
网站性能优化实战—从12.67s到1.06s的故事
本文是对之前同名文章的修正,将所有webpack3的内容更新为webpack4,以及加入了笔者近期在公司工作中学习到的自动化思想,对文章内容作了进一步提升. 0.引言作为互联网项目,最重要的便是用户 ...
网站性能优化实战——从12.67s到1.06s的故事
--本文是对之前同名文章的修正,将所有webpack3的内容更新为webpack4,以及加入了笔者近期在公司工作中学习到的自动化思想,对文章内容作了进一步提升. 原文链接:imweb.io/topic ...
JavaScript系列—性能优化之《网站性能优化实战——从12.67s到1.06s的故事》
本篇博文来源于网络 226 人赞同了该文章原文作者:IMWeb jerryOnlyZRJ 原文链接:网站性能优化实战--从12.67s到1.06s的故事 - 腾讯Web前端 IMWeb 团队社区 ...
从 12.67s 到 1.06s 的网站性能优化实战
作者:jerryOnlyZRJ https://imweb.io/topic/5b6fd3c13cb5a02f33c013bd 本文是对之前同名文章的修正,将所有webpack3的内容更新为webpa ...
从12.67s到1.06s的网站性能优化实战
作者:jerryOnlyZRJ https://juejin.im/post/5b6fa8c86fb9a0099910ac91 本文是对之前同名文章的修正,将所有webpack3的内容更新为webpa ...
炫技，从 12.67s 到 1.06s 的网站性能优化实战
0.引言作为互联网项目,最重要的便是用户体验.在举国"互联网+"的热潮中,用户至上也已经被大多数企业所接收,特别是在如今移动端快速发展的时代,我们的网页不仅只是呈现在用户的PC浏 ...
网站性能优化总结（前端篇）
1.网络传输性能优化这是navigation timing监测指标图,从图中我们可以看出,浏览器在得到用户请求之后,经历了下面这些阶段:重定向→拉取缓存→DNS查询→建立TCP链接→发起请求→接收响 ...

企业应用网站性能优化实例分析

企业应用网站性能优化实例分析相关推荐

最新文章

热门文章