| 系列文章：
大型高性能ASP.NET系统架构设计
构建高性能ASP.NET站点 第五章—性能调优综述（中篇）
构建高性能ASP.NET站点 第五章—性能调优综述（后篇）
大型高性能ASP.NET系统架构设计
网站优化需要考虑的方面
大型动态应用系统又可分为几个子系统： Web前端系统
负载均衡系统
数据库集群系统
缓存系统
分布式存储系统
分布式服务器管理系统
代码分发系统
Web前端系统
为了达到不同应用的服务器共享、避免单点故障、集中管理、统一配置等目的，不以应用划分服 务器，而是将所有服务器做统一使用，每台服务器都可以对多个应用提供服务，当某些应用访问量升高时，通过增加服务器节点达到整个服务器集群的性能提高，同时使他应用也会受益。 该Web前端系统基于IIS/ASP.NET等的虚拟主机平台，提供PHP程序运行环境。服务器对开发人员是透明的，不需要开发人员介入服务器管理。 负载均衡系统 
负载均衡系统分为硬件和软件两种。硬件负载均衡效率高，但是价格贵，比如F5等。软件负载均衡系统价格较低或者免费，效率较硬件负载均衡系统低，不过对于流量一般或稍大些网站来讲也足够使用，比如lvs,nginx。大多数网站都是硬件、软件负载均衡系统并用。 数据库集群系统 
由于Web前端采用了负载均衡集群结构提高了服务的有效性和扩展性，因此数据库必须也是高可靠的才能保证整个服务体系的高可靠性，如何构建一个高可靠的、可以提供大规模并发处理的数据库体系? 我们可以采用如上图所示的方案： 1)使用SQL数据库，考虑到Web应用的数据库读多写少的特点，我们主要对读数据库做了优化，提供专用的读数据库和写数据库，在应用程序中实现读操作和写操作分别访问不同的数据库。 2)使用同步机制实现快速将主库(写库)的数据库复制到从库(读库)。一个主库对应多个从库，主库数据实时同步到从库。 3)写数据库有多台，每台都可以提供多个应用共同使用，这样可以解决写库的性能瓶颈问题和单点故障问题。 4)读数据库有多台，通过负载均衡设备实现负载均衡，从而达到读数据库的高性能、高可靠和高可扩展性。 5)数据库服务器和应用服务器分离。 6)从数据库使用BigIP做负载均衡。 缓存系统
缓存分为文件缓存、内存缓存、数据库缓存。在大型Web应用中使用最多且效率最高的是内存缓存。最常用的内存缓存工具是Memcachd。使用正确的缓存系统可以达到实现以下目标： 1、使用缓存系统可以提高访问效率，提高服务器吞吐能力，改善用户体验。 2、减轻对数据库及存储集服务器的访问压力。 3、Memcached服务器有多台，避免单点故障，提供高可靠性和可扩展性，提高性能。 分布式存储系统
Web系统平台中的存储需求有下面两个特点：
1) 存储量很大，经常会达到单台服务器无法提供的规模，比如相册、视频等应用。因此需要专业的大规模存储系统。 2) 负载均衡cluster中的每个节点都有可能访问任何一个数据对象，每个节点对数据的处理也能被其他节点共享，因此这些节点要操作的数据从逻辑上看只能是一个整体，不是各自独立的数据资源。 因此高性能的分布式存储系统对于大型网站应用来说是非常重要的一环。(这个地方需要加入对某个分布式存储系统的简单介绍。) 分布式服务器管理系统
随着网站访问流量的不断增加，大多的网络服务都是以负载均衡集群的方式对外提供服务，随之集群规模的扩大，原来基于单机的服务器管理模式已经不能够满足我们的需求，新的需求必须能够集中式的、分组的、批量的、自动化的对服务器进行管理，能够批量化的执行计划任务。
在分布式服务器管理系统软件中有一些比较优秀的软件，其中比较理想的一个是Cfengine。它可以对服务器进行分组，不同的分组可以分别定制系统配置文件、计划任务等配置。 它是基于C/S 结构的，所有的服务器配置和管理脚本程序都保存在Cfengine Server上，而被管理的服务器运行着
Cfengine Client程序，Cfengine Client通过SSL加密的连接定期的向服务器端发送请求以获取最新的配置文件和管理命令、脚本程序、补丁安装等任务。 有了Cfengine 这种集中式的服务器管理工具，我们就可以高效的实现大规模的服务器集群管理，被管理服务器和
Cfengine Server可以分布在任何位置，只要网络可以连通就能实现快速自动化的管理。 代码分发系统
随着网站访问流量的不断增加，大多的网络服务都是以负载均衡集群的方式对外提供服务，随之集群规模的扩大，为了满足集群环境下程序代码的批量分发和更新，我们还需要一个程序代码发布系统。 这个发布系统可以帮我们实现下面的目标： 1) 生产环境的服务器以虚拟主机方式提供服务，不需要开发人员介入维护和直接操作，提供发布系统可以实现不需要登陆服务器就能把程序分发到目标服务器。 2) 我们要实现内部开发、内部测试、生产环境测试、生产环境发布的4个开发阶段的管理，发布系统可以介入各个阶段的代码发布。 3) 我们需要实现源代码管理和版本控制，SVN可以实现该需求。
这里面可以使用常用的工具Rsync，通过开发相应的脚本工具实现服务器集群间代码同步分发。
构建高性能ASP.NET站点 第五章—性能调优综述（中篇）
本章的议题如下：
性能调优的一般过程
利用分析工具分析页面加载信息
利用分析工具分析性能瓶颈
利用分析工具分析加载页面信息
站点的优化说到底还是站点每一个页面的优化，即使得站点的页面更快的呈现在用户的眼前。所以在此之前，我们首先来看看一个web页面的组成部分：
1. Html文件:在ASP.NET中，Html文件通常是通过解析.aspx页面而产生的。而这个解析过程在服务端进行，同时这个过程也消耗了服务端的大部分资源。
2. 图片和flash文件：一个站点往往包含很多这样的的文件。
3. Js和css文件：这些文件可以阻止页面的呈现。
清楚了页面的组成部分之后，我们可以把使得页面加载变慢的因素分为如下几类：
1. 服务端的花费大量时间解析.aspx，也就是说服务端产生html文本的时间过长（导致这个问题的原因很多，例如数据库查询很慢，影响了页面的生成）。 2. 在服务端和浏览器之间，传递html文本花费大量的时间（例如，页面中的Viewstate很大，网络很慢等）。 3. 图片和flash文件的加载花费大量的时间。 4. Js和css的加载花费大量的时间。
为了使得一个页面的加载变快，那么我们就得知道：是以上哪一个过程影响了速度(本系列的后续文章会详细讲述)。一旦知道了是那类问题导致了性能问题，那么我们就可以对症下药。
下面我们就通过一些工具来简单的查看和分析站点的性能，目的让大家快速的了解如何进行简单的性能分析。
我们用瀑布图来分析页面的每个组成部分加载所花的时间，例如下面就是博客园首页加载的分析图（部分的截图）。
我们可以通过图中的“时间线“长短来知道每个文件加载的时间。时间线长越长，那么加载该文件的时间越长，反之。
看完了上面的图之后，大家应该很想知道：上面的图是如何生成的，那么下面就介绍一些生成页面加载瀑布图的工具。
我们首先来看看：Firefox+Firebug
Firefox下载地址：http://www.mozilla.com/en-US/firefox/
Firebug下载地址：http://getfirebug.com/
下面就开始演示如何生成页面加载的瀑布图（如果熟悉这个流程的朋友可以跳过此段）
1. 打开Firefox，然后按下F12,就看到如下的画面：
2. 在Firebug中，在选择“网络”下拉框中选择“启用”。
OK，下面我们就来详细的看看在瀑布图中一些数据和图示的意义。
1． 请求和响应的相关信息
在瀑布图中，点击每一行的”+”如下：
符号展开之后，我们可以看到所有的请求和响应头，如下：
2． 时间线的相关信息 当我们把鼠标移到着色的时间线bar上面的时候，我们就可以看到请求该文件所花的时间的详细信息，如下：
我们用一个表格来讲述每个时间段的含义：
3． 页面级的请求信息 也就是整个页面的请求的一些汇总信息。
构建高性能ASP.NET站点 第五章—性能调优综述（后篇）
利用分析工具分析性能瓶颈
在上一节中，讲述了如何使用Firebug来生成页面加载信息的瀑布图，同时也讲述了使得页面加载变慢的四个大的问题：
1. 服务端花费大量时间解析.aspx时间过长。
2. 在服务端和浏览器之间，传递html时间过长
3. 图片和flash文件的加载时间过长
4. Js和css的加载花费时间过长
那么我们下面就根据瀑布图来判断：页面加载变慢，到底是因为哪个因素导致的。
1. 如何判断：服务端花费大量时间解析.aspx时间过长。
在下面的图示中，大家可以看到第一条时间线特别的长：其中紫色的那段表明了在浏览器接受到该页面的第一个字节之前等待的时间。也就是说，在浏览器请求Default.aspx页面之后，浏览器一直处于等待状态。只有浏览器接受到了Default.aspx的DOM之后，才开始下载页面中的其他的资源(css,图片等)。如果在接受Default.aspx的DOM之前等待的时间过长，那么势必影响其他的资源的下载，最后导致整个页面的加载变慢。
如果我们在用firebug生成瀑布图的时候，发现了上面的类似的现象，页面加载变慢的原因很有可能就是服务端在解析Default.aspx页面，生成html文本的时间太长了。至于是什么原因导致了服务端解析Default.aspx时间过长，那么需要进一步的分析。可能是代码写的不好，例如循环问题；可能是数据库问题，例如查询数据太慢或者数据太多等（后续文章详细讲述）。
注：颜色表示的意思： 
2. 如何判断：在服务端和浏览器之间，传递html时间过长
在下面的图中，大家可以看到紫色的线段比较的短，也就是说，服务端解析Default.aspx页面的时间还是比较短的，但是灰色的线段比较的长，。灰色的部分表示接受数据时间很长，也就是说服务端把DOM发送到浏览器，这个过程耗时比较的长。正如之前的问题一样，这个问题也会推迟页面的其他的资源下载，导致整个页面加载过慢。导致这个问题的原因可能是带宽问题，可能是数据过多等。
3. 如何判断：图片和flash等文件的加载时间过长
如下图所示，页面的解析和传送到客户端的时间比较的短，但是页面中的图片加载花费了大量的时间。现在的浏览器一般都会同时打开多个链接，并行的请求多个图片资源，而不是一个个的挨个请求。但是浏览器打开链接的数量是有限制的（不同的浏览器不一样），而且打开新的TCP链接也是需要花时间的，不是链接越多越好。后面我们会讲述如何减少图片等资源的加载时间。
4. 如何判断：Js和css的加载花费时间过长，阻止页面的呈现
如下图所示，在Default.aspx页面载入之后，浏览器就开始解析DOM（从上到下解析，例如head
-> body…）,下载资源。当页面解析到需要加载css和js时，此时浏览器就会去服务端请求这些文件，而用户在浏览器中看到的Default页面将会是一片空白，一直到css和js载入完成之后，页面开始下载图片等，此时页面才会慢慢的呈现出来。
下图就反应了这个问题。
未完待续....... |
