构建WEB站点高性能的研究

肖弋

达州职业技术学院 四川 635000

0 引言

一般而言，人们对一个WEB站点的性能如何，通常都是处于用户的角度，通过访问站点的页面，体验等待所用的时间。当用户输入页面地址后，浏览器便向服务器发出一系列请求，这些请求不光包含了对页面的请求，还包括页面中组件的请求，如：图片，层叠样式表(CSS)、脚本(Script)、内嵌页面(iframe)等。然后浏览器等待服务器的响应之后返回数据，浏览器获得返回数据又要经过本地的计算和渲染，最终呈现完整的页面。

整个过程看似并不复杂，事实上并不简单。对于站点经营者来说，用户等待的时间过长，也许后果就是毁灭性的。在等待的时间里，数据在网络上传输的时间包括两部分，即浏览器主机发出请求数据到达服务器的时间，以及服务器的响应数据回到主机的时间，它的决定因素主要包括发送的数据量和网络带宽。同时，站点服务器处理请求并生成响应数据的时间主要消耗在服务器端，也包括非常多的环节，我们一般用一个指标“吞吐率”来衡量，即每秒处理的请求数。影响服务器的吞吐率的因素有很多，如服务器的并发策略、I/O性能、CPU核数等，当然也包括应用程序本身的逻辑复杂度等。在浏览器本地计算和渲染的时间自然消耗在浏览器端，它依赖的浏览器采用的并发策略、样式渲染方式、脚本解释器的性能、页面大小、页面组件的数量、页面组件缓存状态、页面组件域名分布以及DNS解析等。

可见，一个页面包含了若干个请求，每个请求都会影响页面打开的时间，那么要构建高性能WEB站点，应从以下几个方面进行解决。

1 解决方案

1.1 增加带宽

当WEB站点的网页或者组件下载速度变慢时，架构师可能想到最省事的办法就是增加服务器的带宽，因为他们认为是服务器带宽不够用了，对于一些以提供下载服务为主的站点来说也许是这样，但对于其他服务的站点，也许不一定就是增加带宽的问题，在增加带宽的同时，还要考虑数据的网络传输，如带宽是独享还是共享，数据发送的速度，响应的时间等方面的问题。

1.2 减少网页中的HTTP请求

我们都知道WEB站点中几乎任何一个网页都包含了多个组件，每个组件都需要下载、计算或渲染，毫无疑问，这些行为都会消耗时间。那么如果可以让网页减少这些行为，应该就可以加快网页的展示速度，这是毫无疑问的，但是往往我们需要在优雅的网页表现和性能之间来权衡取舍，这也许就是美和快之间的博弈，找到最优的均衡点至关重要，我们为此做了多方面的尝试和努力：

(1) 设计更加简单的网页，使其包含较少的图片和脚本，但是这可能牺牲美观和用户交互。

(2) 将多个图片合并为一个文件，利用CSS背景图片的偏移技术呈现在网页中，避免了多个图片的下载。

(3) 合并JAVASCRIPT脚本或者CSS样式表。

(4) 充分利用HTTP中的浏览器端CACHE策略，减少重复下载。

很显然，这些技巧都来自于WEB网页前端的优化。

1.3 加快服务器脚本计算速度

我们知道，脚本语言编写的程序文件需要通过响应的脚本解释器进行解释后生成中间代码，然后依托在解释器的运行环境中运行。所以生成中间代码的这部分时间又成为大家为获取性能提升而瞄准的一个目标，对于一些拥有较强商业支持的脚本语言，比如ASP.NET和JSP，均有内置的优化方案，比如解释器对某个脚本程序第一次解释的时候，将中间代码缓存起来，以供下次直接使用。

1.4 使用动态内容缓存

动态内容技术就像WEB开发领域的一场工业革命，它带来了产业升级和WEB开发者的地位提升，自动态内容技术产生后，为了减少动态内容的重复计算，想到了截取动态内容的胜利果实，将动态内容的HTML输出结果缓存起来，在随后的一段时间内当有用户访问时便跳过重复的动态内容计算而直接输出。在实际应用中，动态内容缓存可能是大家使用最多的技术，但是并不见得所有的动态内容都适合使用网页缓存，缓存带来的性能提升恰恰与有些动态数据实时交互的需求形成矛盾，这是非常尴尬的，而解决问题的惟一途径不是技术本身，而是你如何权衡。

1.5 使用数据缓存

动态内容缓存是将数据和表现整体打包，就像快餐店里的组合套餐一样，有时候未必完全合乎口味。当我们意识到在自己的站点中，某些动态内容的计算时间其实主要消耗在一些烦人的特殊数据上，这些数据或者更新过于频繁，或者消耗大量的I/O等待时间，比如对关系数据库中某字段的频繁更新和读取，这时为了提高缓存的灵活性和命中率，以及性能的要求，便开始考虑数据缓存。更加细粒度的数据缓存避免了过期时大量相关网页的整体更新，比如很多动态内容都包含了一段公用的数据，如果我们将整个页面全部缓存，那么假如这段数据频繁更新导致频繁过期，无疑会使得所有网页都要频繁地重建缓存，这对网页的其他部分内容似乎很不公平，所有需要考虑协调网页缓存和数据缓存。另外，数据缓存存储的位置也是需要考虑的多方面因素。速度是一方面，如果无法提供高速的读写访问，那么数据缓存可能不久便成为新的系统瓶颈。另外数据缓存的共享也是至关重要，如同一主机上不同进程间的共享、网络上不同主机间的共享等，一旦设计不当，对站点未来的扩展也是致命的威胁。

1.6 将动态内容静态化

在动态内容缓存技术的实现机制中，虽然避免了可观的重复计算，但每次还需要调用动态脚本解释器来判断缓存是否过期以及读取缓存，这似乎有些多余，而且关键是消耗了不少时间。直接让浏览器访问这些动态内容的缓存不是更好吗？在这种情况下缓存成为直接暴露给前端的HTML网页，而缓存控制机制也发生了根本的变化，我们称它为静态化，静态网页独立了，不用被脚本解释器呼来唤去。

1.7 页面组件分离

在WEB站点中，显然网页和各种各样的组件它们的下载量和对服务器的能力要求不尽相同，如果由同一台物理服务器或者同一种并发策略的WEB服务器软件来统一提供服务，那势必造成计算资源的浪费以及并发策略的低效。所以分离带来的好处是显而易见的，那就是可以根据不同的组件的需求，比如下载量、文件大小、对服务器各种资源的需求等，有针对性地采用不同的并发策略，并且提供最佳的物理资源。

1.8 合理部署服务器

我们都知道，在基于 IP寻址的互联网中，IP地址相近的主机之间通信，数据经过少数的路由器即可到达，比如同一个局域网内通信或者接入同一个城市交换节点的局域网之间通信，在这种情况下数据到达时间相对较短。所以WEB站点服务器部署合理可以减少用户访问数据达到的时间。

1.9 使用负载均衡

至此，我们已经最大程度发挥了单个服务器的处理能力，但是，当它所承受的压力达到极限时，就需要有更多的服务器来分担工作，这时需要将流量合理转移到更多的服务器上。为此，可以通过各种不同的方法来实现WEB负载均衡，可能是简单的HTTP重定向，或者基于DNS的轮询解析，或者通过反向代理服务器来实现负载均衡调度，还可以通过LVS来组建服务器集群等。

1.10 优化数据库

WEB服务器与数据库服务器的数据通信一般基于标准TCP，其通信连接的建立和释放涉及代表一段内核高速缓冲区的文件描述符的创建和销毁，这需要不少的时间开销，包括系统调用导致的内核态切换以及某些异步阻塞 I/O模型采用的文件描述符队列扫描机制。所以，频繁的数据库连接和释放无疑将导致数据访问等待时间的加长，使用数据库持久连接有效的解决了这一难题，它包括不同程度上的持久化，本质的区别在与持久连接的应用范围和生命周期，比如某个进程内部的全局数据库连接，供进程内所有计算机任务共享，在这个进程终止后便被释放；或者在某个动态内容的执行周期内，代码层的持久连接对象，在动态内容计算结束后便不复存在等，这在连接设计时，还需注意数据访问的安全性。

随着时间的推移，WEB站点逐渐被数据库绑架，单台数据库服务器无法应付整个站点的需要，这包括存储空间以及查询时间，数据库模型的不良设计制约横向扩展以及负载均衡，为此，数据散列在多台主机，包括必要的冗余数据，来合理地分散数据库的密集访问等，这都要求必须对数据库进行优化。

2 结束语

随着时间的推移，高性能WEB站点研究的空间还很大，WEB站点在成长的道理上不断吸收新的技术，然而每一次技术的应用不当，都可能让我们面临新的威胁，只有不断地改善才能构建出高性能的WEB站点。

[1] 王春红.中小企业网站安全问题与防范策略研究[J].现代计算机(专业版).2010.

[2] 李博,李宁,费中华.校园网 WEB 服务器的性能测评及优化方案研究[J].电脑知识与应用.2010.

[3] 李春子.网站集群式管理在高校中的应用分析[J].数字技术与应用.2010.

[4] 陈红红.高校网站管理问题分析及解决方案[J].西北成人教育学报.2009.