高性能web优化（一）

高性能web优化（一）:一 用户的请求时间

用户请求网站，等待的时间经历了以下部分时间：

数据在网络上传输的时间分成两部分，一部分是用户请求的数据包到达服务器的时间，另一部分是服务器的回应数据经由网路传送给客户端的时间，这两部分的时间称为响应时间。响应时间的大小取决于带宽和数据量的大小。

响应时间的其中大部分时间消耗在服务器端，我们用吞吐率来衡量这部分时间，即每秒处理请求数。吞吐率影响因素有：服务器的并发策略，I/O模型，I/O性能，服务器硬件配置等，应用程序本身的逻辑复杂度等等。

浏览器端耗时的影响因素有：浏览器采用的并发策略，样式渲染方式，脚本解释器的性能，页面大小，页面组件的数量，页面缓存情况，页面组件域名分布以及域名DNS解析等。

二 性能瓶颈

系统性能的瓶颈，会随着系统的运行发生不断的变化和迁移，比如由于站点用户组成结构的多样性和习惯的差异，导致在不同时段系统的瓶颈各不相同，又如站点在数据存储量或者浏览量增长到不同级别的时候，系统瓶颈也会发生迁移。一旦找到真正影响系统性能的决定因素，就要对其进行调整和优化。

三 增加带宽？

当web站点的网页或者组件的相应速度变慢的时候，一些架构师可能想到的最省事的办法就是增加服务器带宽。对于以下载为主要服务的站点，增加带宽也许可以解决问题，但 对于其他类型的网站，如何判断是否是带宽不够？当前网站的带宽如何衡量？增加带宽就一定能使响应速度加快吗？使用独享带宽和共享带宽的本质区别是什么？如何在日常开发中，注意节省带宽的问题？

在后续的文章中，将会做出探讨。了解网络原理，是一个优秀架构师必须掌握的知识。

四 减少http请求

如果让浏览器请求网页的时候，减少网页上的Http请求，毫无疑问将会加快网页的请求速度

五 加快和优化服务器端的脚本计算速度

使用脚本语言编写的程序文件需要通过相应的脚本解释器进行解释后生成中间代码，然后依托在解释器的运行环境中运行，所有生成中间代码的这部分时间成了优化的一个重要点。ASP和JSP，均有内置的优化方案，比如解释器对某个脚本程序第一次解释的时候，将中间代码缓存起来，以便下次直接使用。对于开源的脚本语言，也有第三方组件来提供此类功能，比如PHP的APC组件等。

六 使用动态内容缓存

在实际生产中，动态内容缓存是使用得比较多的技术，但不是所有的动态内容都适合网页缓存，缓存带来的性能提升和有些动态数据实时交互的去修形成矛盾，这是一个需要权衡的问题。

另一方面，成千上万的缓存文件如何存储？缓存的命中率如何？缓存的过期策略如何设计？在拥有多台web服务器的分布式站点上应用动态内容缓存需要考虑一些什么问题呢？后续的文章将会做出探讨

七 数据缓存

动态内容缓存是将数据和变现整体打包，有的适合不太适合业务场景。当我们的站点中某些动态内容的计算时间主要小号在一些特殊数据上，这些数据或是更新过于平凡，或是小号大量的I/O等待时间，比如对数据库中某字段频繁更新和读取，这是我们为了提高缓存的灵活性和命中率，以及性能的要求，便开始考虑数据缓存。

更加细粒度的数据缓存避免了过期时大量相关网页的整体更新，比如很多动态内容都包含了一段公用的数据，如果我们将整个页面都缓存，那么加入这段数据频繁更新导致这个整个网页都要频繁地重建缓存，这对网页的其他部分内容不太公平。

后面的文章将会对数据缓存做出讨论

八 更换web服务器软件

大量的压力测试对比数据蛊惑激进的开发者和运维工程师，只关注所谓的并发量冠军，却忽视了更加本质性的东西，甚至不了解测试数据的潜在前提。有人拿着数据说apache已经过时，我们必须停止表面现象的崇拜。

九 页面组件分离

不同业务对服务器的要求不尽相同，所以分离带来的好处是显而易见的。针对不同业务采用不同的并发策略，并且提供最合适的物理资源。

十 合理部署服务器

实际生产中，跨运营商的网络通信是必须要考虑到的问题。如果通信的两段主机位于不同运营商的互联网中，那么数据必须流经两个互联网运营商的顶级交换节点和骨干网络，在这个过程中还要经过更多次的存储转发，而且个互联网顶级交换节点之间又存在出口带宽的限制，如果互联网之间数据通信量比较大的话，那么这个顶级交换节点，也就是出口，将会是瓶颈所在。

我们当然希望web站点的用户和服务器位于同一个互联网运营商的网路内，但如何实现，以后的文章将会做出探讨

十一 使用负载均衡

当单台服务器所承受的压力达到极限时，就需要更多服务器来分担工作，我们需要将流量和用户请求转移到更多服务器上。

为此，我们需要通过不同的方法来实现web负载均衡，可能是简单的http重定向，或者是基于dns的轮询解析，或者通过反向代理服务器来实现负载均衡调度，还可以通过lvs来组建服务器集群。通过这些具体的实现方法，我们更加关心的是，是否具备高可用性，还有影响规模拓展的制约因素。这些以后的文章将会做出探讨。

十二 优化数据库

一些性能问题往往发生在表现不佳的数据访问层面，这来源于不合理的应用程序数据访问组件设计，不合理的数据库表结构设计以及对数据库内部构造缺乏深入的了解，web服务器和数据库服务器的数据通信一般基于标准的tcp，即便他们位于同一台物理主机上也是如此。

其通信连接的建立和释放涉及代表一段内核缓冲区的文件描述符的创建和销毁，这需要不少的时间开销，包括系统调用导致的内核态切换以及某些异步阻塞I/O模型采用的文件描述符队列扫描机制。所以，频繁的数据库连接和释放将导致数据访问等待时间的加长，这段时间浪费得毫无意义。

使用数据库的持久连接能有效解决这一难题，它包括不同程度上的持久化，本质的区别在于持久连接的应用范围和生命周期，比如某个进程内部的全局数据库连接，共进程内所有计算任务共享，在这个进程终止后便被释放；或者在某个动态内容的执行周期内，代码层面的持久连接对象，在动态内容计算结束后便不复存在；还有跨进程的数据库连接池，保存多个持久连接供应用程序重复使用。在这些采用数据库持久连接的应用设计中，同时还要注意保证数据访问的线程安全性。

另外，索引的合理使用对于以来数据库访问的web应用至关重要。以及还要考虑到针对不同存储引擎的取舍。

数据库模型的不良设计制约了横向拓展和负载均衡，为此，我们将数据散列在多台主机，包括必要的冗余数据，一次来合理地分散数据库的密集访问，数据库扩展便成为我们考虑的方案

十三 可扩展性

无论是代码层面的扩展，还是架构层面的扩展，涉及的内容非常多，缺乏良好的可扩展性设计就像慢性自杀或者等待死亡，这比web汉典所能遇到的其他一切困难更让人头疼，一旦扩展无法进行，就是死路一条

可扩展性的目的在于适应负载的变化，从扩展的技术实现上来看，又包含了很多对局部性能的思考，以及了解何时需要扩展，这离不开对于站点性能的把握

每一次技术的应用不当，都可能引入一定程度上的不可扩展。但实际生产中，不得不采用一些技术来构建web站点，这些技术可能就会引起不可扩展性。正确理解业务，做出取舍。