响应时间

各项硬件的资源,如CPU、内存、硬盘输入输出、网络带宽等等。在实际查看架构之前,先强调一个观念,不管是使用系统上哪一种资源,当使用率持续超过80%时,系统的性能一定会急速下滑,而不会显示线性关系,如下图所示:

使用率        80%
           资源使用率与系统响应时间的关系
注:从《操作系统》的知识来理解,如果在多用户环境中cup的使用率大于80%,进程就会在运行队列中花费大量的等待时间,响应时间和吞吐量就会下降。
3.1,内存Memory
      通常系统中所发生的问题是由于内存不足所导致,这是较常见的。所以我们应该先监视内存,确认我们的服务器有足够的内存。若要执行 windows 2000 上的 iis 5.0(如MOD的web服务),一个专用web 服务器所需 ram 的最小容量是 128mb,但最好是 256mb 到 1gb。因为「iis 文件缓存」默认是使用最多一半可用的内存,因此备有的内存越多,「iis 文件缓存」就越多。

  附注:windows 2000 advanced server 最多可支持 8gb 的 ram,但是「iis文件缓存」将不会利用 4gb 以上的 ram。
     所有在Windows系统执行的应用程序都以为自已最起码有2GB的连续内存(称之为虚拟内存),当应用程序的线程在存取内存时,操作系统会将其映射(mapping)到某块物理内存,若物理内存不足,操作系统就把物理内存中某些较少用到的区块写至硬盘,以空出该物理内存给当前需要的程序。
Available MBytes 可用物理内存数  
     说明:Available MBytes 是计算机上运行进程可用的物理内存数量,以兆字节为单位。通过计算清零、空闲和待命内存列表的内存空间总数而得到。空闲内存可以马上使用; 清零内存是由零值填满的内存页,用来防止后续进程获得旧进程使用的数据; 待命内存是从进程工作集(其物理内存)中删除然后进入磁盘的内存,但是该内存仍然可以收回。该计数器仅显示最后一次观察到的值; 不是平均值。
     技 术 :一般要保留10%的可用内存。最低最低不能<4M,此值过小可能是内存不足或内存泄漏;
     原 因 :因为IIS默认最多会使用50%的可用内存供文件缓存使用,所以要保留10%的可用内存(以供尖峰时间使用)。
     知识点:物理内存、虚拟内存、IIS文件缓存、清0内存(程序常发生的错误)、待命内存。

Page Faults/sec、Pages Input/sec、Page Reads/sec
    注(重要):导致严重的延迟原因:是因为硬件分页错误。
     说 明: Page Faults/sec 是指处理器处理错误页的综合速率。用错误页数/秒来计算。当处理器请求一个不在其工作集(在物理内存中的空间)内的代码或数据时出现的页错误。这个计数器包括硬错误(那些需要磁盘访问的)和软错误(在物理内存的其它地方找到的错误页)。许多处理器可以在有大量软错误的情况下继续操作。但是,硬错误可以导致明显的拖延。
      Pages Input/sec 指为解决页错误从磁盘上读取的页数。(当处理需要不在其工作集或物理内存的任何地方的代码或数据,而需要从磁盘上检索时出现硬页错误)。
             Page Reads/sec 是指为解析硬页错误而读取磁盘的次数。(当处理请求的硬 页错误不在工作集和物理内存其它地方中的代码或数据,而必须从磁盘上检索时 就会出现硬页错误)。如果 Page Reads/Sec 比率持续保持为 5,表示可能内存不足(阈值为>5.越小越好)。

可能引起页面错误的操作:应用程序向内存请求一个分页,但系统无法在所需的位置上找到它,就构成了一个页面错误。
     技 术:
         总述:可能涉及到1,由于页交换而导致内存不足;2,由于页交换而导致磁盘瓶颈;
               当这些值很低时,服务器应该可以很快地响应请求;当这些值较高时,是因为你花了太多的内存在缓存处理上,而没有留足够的内存供系统的其它部份使用。可以增加内存或降低缓存的ram大小来解决;
         详细:
              page Faults/sec:只表明数据不能在内存的指定工作集中立即使用;
              page Input/sec: page input/sec > page reads/sec;
              page Reads/sec: 阈值为>5.越小越好,大数值表示磁盘读而不是缓存读;
Page/sec:指为解析硬页错误从磁盘读取或写入磁盘的页数(是Pages Input/sec 和 Pages Output/sec 的总和)。其值推荐00-20如果服务器没有足够的内存处理其工作负荷,此数值将一直很高。如果大于80,表示有问题(太多的读写数据操作要访问磁盘,可考虑增加内存或优化读写数据的算法),如果值比较低,说明Web 服务器响应请求比较快,否则可能是服务器系统内存短缺引起( 也可能是缓存太大,导致系统内存太少)。

3.2,Processor
随着用户请求从网站获得快速的响应时间,以及在这些网站上不断增加的动态内容,需要利用到快速、有效的处理器用量。当一个或多个进程几乎耗尽所有处理器时,就会发生瓶颈,这会迫使准备好执行的进程线程必须在队列中等待处理器时间。
(web方面) windows 2000 及 iis 5.0 的最大性能增益来自于解决内存问题。在决定改变web 服务器上处理器的个数之前,请先排除内存问题,再监视下列「性能计数器」。
% Processor Time 指处理器执行非闲置线程时间的百分比;通俗一点讲就是CPU 使用率。这是监视处理器活动的主要指示器。它通过在每个范例间隔中衡量处理器用于执行闲置处理线程的时间,并且用100%减去该值得出。(每台处理器有一个闲置线程,该线程在没有其它线程可以运行时消耗周期)。可将其视为范例间隔用于做有用工作的百分比。
正常值<90,此值过大表示处理器的性能已经不能应付程序的要求,要换更快的处理器。该数值持续超过 90%,则表示此测试的负载对于目前的硬件过于沉重。排除内存因素,如果该计数器的值比较大,而同时网卡和硬盘的值比较低,那么可以确定CPU 瓶颈。

Processor Queue Length:是指处理列队中的线程数。显示在由 Web服务器所有处理器共享的队列中等待执行的线程数。如果处理器列队中总是有2个以上的线程通常表示处理器堵塞。
参考值:小于2。处理器瓶颈会导致该值持续大于 2。

3.3, Physical Disk:
    因为 MOD的WEB(iis 5.0) 会将记录文件写入磁盘上,所以在一般磁盘活动中,甚至会有高达 100 % 的客户端缓存存取次数。一般来说,如果有记录以外的大量磁盘读取活动,即表示系统上有其它区域需要调整。例如,硬件分页错误会导致大量的磁盘活动,但它们表示 ram 不足。

%Disk Time %:  指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大,那么硬盘不是瓶颈。如果只有%Disk Time比较大,另外两个都比较适中,硬盘可能会是瓶颈。在记录该计数器之前,请在Windows 2000 的命令行窗口中运行diskperf -yD。正常值<10,此值过大表示耗费太多时间来访问磁盘,可考虑增加内存、更换更快的硬盘、优化读写数据的算法。若数值持续超过80 (此时处理器及网络连接并没有饱和),则可能是内存泄漏。

Pages per second :  每秒钟检索的页数。该数字应少于每秒一页。

如果这三个计数器(processor: % processor time, network interface connection: bytes total/sec及physicaldisk: % disk time)的值都很高,则硬盘不会引起站点的瓶颈。

补充:
  Avg. Disk Queue Length 指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。正常值<0.5,此值过大表示磁盘IO太慢,要更换更快的硬盘。
  Disk Transfers/sec 指在此盘上读取/写入操作速率。正常值<(Disk Bytes/sec)/3,此值过大表示系统要求的IO速度已接近硬盘的最大速度,要更换更快的硬盘。
    磁盘使用情况计数器和内存计数器(磁盘瓶颈or内存不足?):
Physical Disk\ % Disk Time 、Physical Disk\ Avg.Disk Queue Length 例如,包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果页面读取操作速率很低,同时 % Disk Time 和 Avg.Disk Queue Length的值很高,则可能有磁盘瓶径。但是,如果队列长度增加的同时页面读取速率并未降低,则内存不足。

3.4, 网络容量、等待时间及带宽  
  测试目标:在系统试运行之后,需要及时准确地了解网络上正在发生什么事;什么应用在运行,如何运行;多少PC正在访问LAN或WAN;哪些应用程序导致系统瓶颈或资源竞争
作用
1,分析关键应用程序的性能
2,定位问题的根源是在客户端、服务器、应用程序还是网络
3,哪些应用程序占用大量带宽
  基本上,网络是客户端向服务器传送请求的线路。它花在您的服务器上来回传递这些请求及响应的时间,对用户能察觉的服务器性能来说是个最大限制因素之一。这种请求-响应的循环时间就称为等待时间,等待时间对于web 服务器管理员来说几乎是无法控制的。例如,您对 internet 上速度缓慢的路由器,或是客户端及服务器之间的物理距离所能作的处理实在不多。
   在主要是由静态内容组成的站点上,网络带宽最有可能是性能瓶颈的来源。即使是一般的服务器也可能用满一条 t3 连接 (45mbps) 或 100mbps fast ethernet 连接。测量有效带宽最简单的方法是判定您的服务器是以哪个速度传送及接收资料的。
Network Interface Bytes Total/sec: 为发送和接收字节的速率,包括帧字符在内。判定网络连接是否存在瓶颈。若要在传送量中留些空间供尖峰时间用,则不应常使用超过 50% 的容量。如果这个数字十分接近连接的容量,而处理器及内存的使用都很适中,则此连接也会是个问题。参考值:该计数器的值和目前网络的带宽相除,结果应该小于50%。
如果您正在计算机上执行的其他服务也使用网络连接,请监视「web service: maximum connections」及「web service: total connection attempts」计数器,以检查您的web服务器是否能够尽可能地使用它需要的连接数目。请记得将这些数字与内存及处理器使用量作比较,如此才能确定连接就是问题,而不是其它组件有问题。
Connection Attempts/sec:Web服务尝试连接的频率。
Maximun Connections:“最大连接数”是和Web服务同时建立起来的最大连接数。

时间: 2024-10-02 13:45:36

响应时间的相关文章

SylixOS 中断响应时间测试

1.应用场景 在一些情况下,对于一些紧急的中断任务,系统需要为其提供稳定可靠的中断响应时间,但一般的中断服务函数,它的响应时间可能会受到其他中断向量的影响,延迟响应.在SylixOS中有两种解方案. 1.提高该中断向量优先级,打开中断嵌套来确保紧急中断的响应时间. 2.对于多核处理器,可以采用中断绑核的形式,即将紧急中断绑定到某一核上,该核只处理紧急任务. 下面通过测试正常情况下.中断嵌套情况下.中断绑核情况下的中断响应时间,来对比采用上述两种方式的优点. 2.中断响应时间测试方案 使用示波器自

tps 与 事务平均响应时间关系对答(转)

问者:每秒处理的事务数和事务的平均响应时间 怎么个关系,有关系吗 kaku21:举个例子:一个高速路 有10个入口,每个入口每秒钟只能进1辆车,请问1秒钟最多能进几辆车?? 问者:10 kaku21:每辆车需要多长时间响应?? 问者:针对这个问题的话 那tps就是10 ,事务的响应时间是1 kaku21:好,那现在我有20辆车,那每秒能进几辆??每辆响应时间是多少?? 问者:...思考中 kaku21:每秒还是进10辆车呗,每辆车还是1秒响应啊 问者:对呀 kaku21:继续,现在我把入口扩展到

IOS动态修改按钮响应时间

在项目开发中我们可能会遇到这样子的情况,比如在我们登陆的时候需要把数据发送给服务器进行比对,通常我们的做法是当用户点击按钮后,使用一个加载效果的view遮挡住当前界面,直到服务器返回数据或者超时.如果不进行遮挡,用户可能频繁的点击登录,而你又一直发送数据,这样子显然是不信的,解决这样子的方法有很多种. 今天我们说一种方式,让按钮响应时间由自己控制.要想达到这种效果你可能需要去了解一下什么是 Runtime OK,如果你不是很了解也没有关系,对于这个功能用到的也不多.其中包括: 1 objc_ge

如何减少接口响应时间

remature optimization is the root of all evil. — Donald Knuth 对于程序优化,我一直采取保守的态度,除非万不得已.但是随着业务的不断发展,程序越来越复杂,代码越写越多,优化似乎是终有一天会到来的事情. 那么对于一个典型的后台服务接口,我们可以从那些方面入手进行优化呢? 接口拆分 接口垂直拆分 垂直拆分可以简单理解为微服务化,把一个大而复杂的服务拆分成多个相互独立,职能单一的服务,单独部署. 更细粒度拆分的好处是,能对某个具体的微服务进行

TPS和事务响应时间的关系

例子:一个高速路有10个入口,每个入口每秒钟只能进1辆车 1.请问1秒钟最多能进几辆车? TPS=10 2.每辆车需要多长时间进行响应? reponse time = 1 3.改成20辆车,每秒能进几辆?每辆车的响应时间是多长? TPS = 10,reponse time = 1 4.入口扩展到20个,每秒能进几辆?每辆车的响应时间是多长? TPS = 20,reponse time = 1 5.看看,现在TPS变了,响应时间没变,TPS和响应时间有关系吗? 木有关系 6.如何理解? TPS和响

网站吞吐量和并发量以及响应时间的联系

吞吐量和并发量以及响应时间之间的关系可以理解为高速公路的通行状况: 吞吐量是每天通过收费站的车辆数量(可换算成收费站收取的高速费),并发量是高速公路上的正在形式的车辆数目,响应时间是车速.车辆很少的时候,车速很快,但是收到的费用也很少:随着车越来越多,车速略受影响,但是收到的高速费增加很快:随着车辆继续增加,车速越来越慢,高速公路越来越堵,收费的不增反降:如果车流量继续增加,超过某个值以后,任何偶然因素都将导致高速瘫痪,车辆走不动,费用也收不着了,而高速公路变成了停车场(资源耗尽).

fidder监控请求响应时间和请求IP(摘抄至网络)

增加监控请求的详情时间 在CustomRules.js的class Handlers中增加 //添加请求的响应时间 public static BindUIColumn("Time Taken")           function CalcTimingCol(oS: Session){             var sResult = String.Empty;             if ((oS.Timers.ServerDoneResponse > oS.Timer

性能测试_响应时间、并发、RPS的关系

写这篇文章是为了帮自己理清一下性能测试中最最基本,却总是被人忽略的一些概念. 并发: 什么叫并发?并发不是我们理解的在loadrunner场景中设置并发数,而是正在系统中执行操作或者在系统的队列中排队的用户数,当然在lr的世界里,我们也会粗略的认为二者相等. 响应时间: 严格意义上说是从客户端发送请求开始,到客户端接受到服务器的返回结束.在我们测试环境中,客户端和被测服务器往往在一个机房一个网段甚至同一个交换机, 所以我们通常把响应时间认为是服务器处理请求所耗费的实际 RPS:每秒请求数,这里还

峰值QPS/QPS/PV/UV/服务器数量/并发数/吐吞量/响应时间计算公式

原地址:https://segmentfault.com/q/1010000000503888 QPS:每秒查询率(Query Per Second) ,每秒的响应请求数,也即是最大吞吐能力.QPS = req/sec = 请求数/秒QPS统计方式 [一般使用 http_load 进行统计]QPS = 总请求数 / ( 进程总数 * 请求时间 )QPS: 单个进程每秒请求服务器的成功次数 峰值QPS:原理:每天80%的访问集中在20%的时间里,这20%时间叫做峰值时间公式:( 总PV数 * 80

高并发应用中客户端等待、响应时间的推算,及RT/QPS概念辨析

高并发应用中客户端等待.响应时间的推算,及RT/QPS概念辨析 对于一个网站,已知服务端的服务线程数和处理单个请求所需的时间时,该如何算出高并发时用户从点击链接到收到响应的时间?注意这个时间并不等于服务端处理单个请求的时间,因为高并发时,很多用户请求需要排队等待,你要把这个额外的等待时间算进去. 这个问题很重要,因为它的结果直接影响你的网站的用户体验.这篇文章就是来帮你算这个时间的.你可以使用本文附带的程序来算,也可以通过本文提炼出的公式来算. 另外还有一个问题:所谓RT(响应时间)和QPS,究