注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

伯纳乌の夢

可以挽回么?我们按“ Ctrl+Z”撤销掉吧。对不起啦~~

 
 
 

日志

 
 
 
 

[转]构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优(上篇)—识别性能瓶颈  

2011-04-15 23:53:47|  分类: Web |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
[本文转自]http://www.cnblogs.com/yanyangtian/archive/2011/02/14/1954005.html


构建高性能
ASP.NET站点 第六章性能瓶颈诊断与初步调优(上篇)识别性能瓶颈

 

    前言:从本篇开始就真正的进入了性能调优的阶段,在之前的文章中提到了页面加载过慢的四个性能问题,其中第一个问题就是:服务端解析.aspx页面的时间过长,本篇就分析这个问题,给出一些方案,因为涉及到的问题很多,的在后续文章会逐个详细介绍。

 

    因为本篇的篇幅过长,所以划分为了多篇。 

   本篇的议题如下:

   识别和分析服务端的性能瓶颈()

  内存

  缓存

   CPU

  处理请求线程

提高性能的一些改进措施(下)

         部署优化(前篇)

         不必要回传(中篇)

         不必要的请求(后篇)

        

 

  系列文章链接:

  构建高性能ASP.NET站点 开篇

  构建高性能ASP.NET站点之一 剖析页面的处理过程(前端)

  构建高性能ASP.NET站点之二 优化HTTP请求(前端)

  构建高性能ASP.NET站点之三 细节决定成败

  构建高性能ASP.NET站点 第五章—性能调优综述(前篇)

  大型高性能ASP.NET系统架构设计  

  构建高性能ASP.NET站点 第五章—性能调优综述(中篇)

  构建高性能ASP.NET站点 第五章—性能调优综述(后篇)

  构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优(上篇)—识别性能瓶颈

  构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优(下前篇)—简单的优化措施

  构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优(下后篇)—减少不必要的请求  

  构建高性能ASP.NET站点 第七章 如何解决内存的问题(前篇)—托管资源优化—垃圾回收机制深度剖析

  构建高性能ASP.NET站点 第七章 如何解决内存的问题(前中篇)—托管资源优化—监测CLR性能

 

在服务端有很多可以优化的地方,优化的话题也很多,在本篇中我们主要关注:如果让服务端更快的生成页面,同时也关注如果更快的让生成的页面更快的到达客户端浏览器。

其实我们就是在优化下面的时间线:

 

 

 

 

要缩短上面的那条时间线,就需要服务端更好的利用它的资源,例如更好的利用和分配内存资源,CPU资源等。如何好的充分利用这些资源,一定程度上与我们写的代码的质量息息相关,一段好的,高效的代码往往可以让我们少花钱去更多的硬件设备(所以代码的质量非常重要)。 

         下面我们就来看看服务端一般可能出现的性能瓶颈:

         内存不足

         缺乏缓存

         CPU压力

         处理请求线程问题

 

接下来会介绍如何采用系统的性能诊断工具来辨明:到底是哪种性能瓶颈导致了服务端解析页面过慢。在用性能诊断工具找出了问题之后,然后针对问题再次做详细的分析,同时收集数据,根据这些数据来采用对应的措施,对症下药。至于每一种性能问题如何采取何种措施解决,我们后面的文章会一章章的详细详述,请大家稍安勿躁,在此我们先学会发现问题。发现站点的可能出现了性能问题之后,首先不要立刻的修改站点或者服务器,而是要先诊断出瓶颈出现在哪里。

      内存

         首先要判断服务器是否内存不足。因为如果内存不足,那么会增加服务器的CPU压力和磁盘的IO读写操作,返过来说,如果解决了内存不足的问题,自然而然的就减少了CPU和磁盘IO读写操作。

 

         为什么内存不足会增加CPU的压力和磁盘的IO读写操作?

         当系统的内存不足的时候,系统就会把原来需要放在内存的一些数据转移保存在磁盘上面,保存为pagefile.sys。当这些数据被需要的时候,那么系统就会去读写磁盘。读写磁盘的操作会消耗CPU资源,同时增加了磁盘的IO操作。

 

         下面我们就来看看,如何识别内存不足性能瓶颈。

         我们主要讲述如何在Window服务器系统中诊断这个问题。

 

         Window Server 2003

         在系统的命令行中输入perfmon。就会弹出如下的窗口。然后点击工具栏上面的”+”按钮,在Performance object下拉框中选择Memory,然后再选择Pages/sec计数器。如果这个值很大,就说明CPU在内存和磁盘之间不断的交换数据。

 

 

        

   

         Windows Vista, Server 2008, Window 7

         Windows VistaWindows Server 2008Window 7中不仅可以运行”perfmon”,打开性能监视窗口。而且可以运行resmon来开启资源监视窗口,从这个窗口看,可以更加直观。在资源监视窗口中看到硬错误/”(Hard Faults/sec).然后检查每个进程的这个值,如果进程的硬错误/数值很高,那么就说明服务器已经是内存不足了。(我们将会在后续的文章讲述如何解决这个问题,此处我们先讲述如何找出这个问题)

 

 

 

     

     缓存 

         大家都知道,在适当的实用缓存策略可以极大的提高服务端的性能。我们一般把数据缓存在内存中,例如浏览器的内存,代理服务器的内存等。而且可以把一些常用的对象,部分的页面,甚至整个页面缓存起来。

 

         缓存的好处有很多,如下:

                  缩短服务端的响应时间

                  减少CPU的使用压力

                  避免频繁的读取数据库

                  如果把数据缓存在浏览器或者代理服务器,还可以减少不必要的回传。    

 

         一般来说,我们把一些使用很频繁的数据或者每次生成都要花费大量资源的数据缓存起来。

      但是如何才算得上是使用很频繁

      没有一定的标准了,还是那句话:看情况!例如,如果一个页面在1秒钟之内被请求了10次,可能相比较其他的页面而言,这个页面的请求不算””频繁(其他的页面在1秒之内请求100),但是如果把这个页面缓存1秒,也是对性能的极大提升,因为可以一秒之内,有90%的请求都是由缓存响应的。大家可以去参看一下缓存的5分钟法则。至于如何进行缓存,在后面的文章讲解。

  CPU

   还是和之前内存诊断一样,我们可以运行perfmon命令,然后在Processor分类下面选%Processor Time计数器。如下:

 

 

 

   

    同时,我们还可运行resmon来打开“资源监视窗口”来看:

 

   

 

 

     大家可以看到第一个标红色框的CPU列,其实这个就是反应了 %Processor Time计数器监控的结果。一般来说,如果某个进程的这个值高于了80%,那么就说明这个进程对CPU资源有很大的消耗。如果是w3wp.exe这个进程消耗了80%,就说你的站点消耗了大量的CPU。我们会在后续的文章讲述:如果减小CPU的压力。

 

  处理请求线程

 

我们知道:发送到服务器的每一个请求,都是有应用程序池中的一个线程来处理的。而且用来处理请求的线程的数量是有IIS来控制的,如果应用程序池中没有空闲的线程来处理新的请求,那么这个请求就被放在请求队列中进行等待。如果在服务端的请求队列太长了,服务器忙不过来,那么新来的请求很有可能被服务器拒绝。

 

         一般来说,一个应用程序池中的可用的线程数量由服务端安装的.NET Framework的版本和IIS的一些设置来决定的。

.NET Framework Version

默认的可用线程数

1.1

20*CPU的数量-8

2.0

12* CPU的数量

3.5, 4.0

IIS 7经典模式:12* CPU的数量

 

IIS 7 集成模式: 100* CPU的数量

 

   如果在服务端没有足够的线程来处理请求,这种情况就是所谓的线程饥饿。我们可以通过系统的性能计数器来检查站点的服务端是否发生了这种情况:

1.       在命令窗口运行perfmon”.如下:

 

2.       在打开的性能监视窗口中,选择性能监视器,如下:

 

3.       点击“+”按钮,然后展开ASP.NET分类:

 

4.       添加如下计数器:

Request Execution Time

处理一个请求花费的时间(单位是:毫秒)

Request Current

现在ASP.NET运行时要处理的请求数量,包括正在处理的请求和等待队列中的请求。

 

5.       然后展开ASP.NET Applications”分类,添加如下计数器:

Request Executing

现在正在被处理的请求数

如果”Request Current”的数量大于了Request Executing的数量,那么就说明有请求在等待被处理。后面的文章会详细讲述如何处理这种情况。

 

 

如果”Request Current”的数量大于了Request Executing的数量,那么就说明有请求在等待被处理。后面的文章会详细讲述如何处理这种情况。

 

     OK,今天就暂时发上这些,贵在理解和操作。下一篇接着讲述。 

 

作者:小洋,燕洋天
出处:http://yanyangtian.cnblogs.com/

AgileSharp Team(Chief Architect)

本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利.

  评论这张
 
阅读(135)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018