.net+sql server企业应用性能优化笔记2——查找瓶颈.docVIP

精品word文档 值得下载 值得拥有 精品word文档 值得下载 值得拥有 前面一篇文章中我已经对项目的基本情况进行了简单的介绍，今天就开始动手针对系统进行性能调优。在性能调优上面说实话我算是个菜鸟，并没有太多的经 验和扎实的基础，所以有错误的地方希望大家指出。 对于一个BS的系统来说，总共涉及到3个角色：Web服务器、数据库服务器和客户端。性能调优的第一步也是最重要的一步就是查找瓶颈。到底是Web 服务器中的程序有问题还是数据库服务器上的SQL查询语句有问题，或者是客户端上的HTML、JS、Flash、SilverLight、图片有问题？就 算知道了是哪个角色出现了问题，那么到底是CPU上的问题、内存问题、磁盘IO问题还是网络问题？如果没有找到瓶颈就开始调优，那无异于缘木求鱼。举个简 单的例子，如果一个页面客户端请求要10秒钟系统才响应，在网络传输和浏览器展现上用了1秒，Web服务器进行逻辑处理和运算用了8秒，SQL服务器进行 数据查询用了1秒，如果错误的将瓶颈判断为SQL服务器，对SQL查询进行调优，废了九牛二虎之力将查询效率提高了100倍（只需要0.01秒），单从 SQL调优上来说算是比较成功的，但是从整体而已，客户端请求该调优后的页面还是要花9.01秒，用户可能根本感觉不到10秒和9.01秒的差别，所以整 个调优是失败的。 前面说到BS系统中的3个角色：Web服务器、数据库服务器和客户端。要查找瓶颈在哪个角色上，最好的情况是这3个角色是3台不同的计算机，而且这 3台计算机最好比较单纯，也就是说Web服务器上就只跑了一个IIS，其他什么服务都不跑，SQL服务器上只运行了SQL Server，客户端只运行了个IE，而且IE只打开了我们要调优的这个系统。一般来说，大多数瓶颈都是出现在WEB服务器或SQL服务器上，很少有在客 户端出现瓶颈的。（不过我还真遇到过客户端出现性能瓶颈的情况，由于使用了一个不正确的GIF图片，该图片导致客户端CPU占用100%，使得用户感觉系 统响应很慢。） 首先确认瓶颈是否在客户端。调查用户在使用该BS系统时的硬件和软件环境，是不是只有配置低的电脑才感觉系统缓慢？是不是只有使用了FireFox 的用户才感觉系统缓慢？用户在使用该系统时是不是CPU占用过高？通过对客户端的一些调查就可以确定瓶颈是否在客户端了。真是在客户端的话那就要优化 JS、优化HTML等。 确认了瓶颈没有在客户端，那么剩下的就是2台服务器。要确定到底是哪台服务器的问题，用到的主要工具就是Windows计数器。在使用 Windows计数器之前还可以使用Windows的任务管理器来大概的查看一下CPU、内存、进程的使用情况。但是切不可看到数据库服务器的CPU高就 说是数据库服务器的问题，也可能是WEB服务器上运行的程序有问题。我以前就遇到过这样的情况，即使是在业务低谷期（下班后，晚上时间）数据库的CPU占 用率一直居高不下，经过好长时间的分析，终于找到原因，原来是程序里面写了死循环，在不断的执行数据库操作。另外，就算能够确定是数据库的问题，也不能因 为CPU占用高就认为是执行的运算太复杂，其实更大的可能是因为对数据的IO太多。大量的IO操作可能造成CPU负担加重。 在Windows计数器中可以监视系统的内存、CPU、磁盘还有各应用程序自身提供的计数器（SQL Server、Asp.Net等都有自身的计数器）。要监视系统的内存情况可以添加Memory下的Pages/sec ，这个计数器表示物理内存和硬盘上的虚拟内存的分页交互情况，数值越大，表示系统读写虚拟内存频繁，主机繁忙，平均值一般在20以下最好。另外还有大量的 ASP.NET和SQL Server的计数器，我就不一一介绍了。 如果环境允许，我们将业务系统转移到测试环境中，而且是将Web服务器和SQL服务器分开，同时如果能够让测试环境和生产环境的硬件配置和网络配置 这些都差不多那就更好了。使用LoadRunner或者是VS或者其他压力测试工具模拟多个用户对性能有问题的页面进行压力测试，同时开启服务器上的相关 计数器。通过对两个服务器的监控，基本上就可以判断出到底哪个服务器存在性能瓶颈。 如果要获得更详细的性能瓶颈信息，那么需要获得程序的源代码，然后修改源代码在其中加入记录时间的代码，在页面初始化的时候、调用数据库之前、调用 数据库之后、页面Render完成之后分别加入记录时间的代码，将这些时间记录下来，然后可以得到页面载入的时间，调用数据库花费的时间。比如页面载入花 了10秒钟，从时间记录上看，调用数据库花了9秒钟，那么说明性能的瓶颈是在数据库上，而不是在Web服务器上。 另外还有一种办法可以获得函数调用的时间，那就是使用.net性能跟踪的工具ANTS Profiler，这个工具是Re