性能监控随笔点滴 - pcl

吞吐量：

  定义：单位时间内完成工作的度量。
  评估点：在C/S环境中通常是从服务器方进行评估。
  表象：随着负载的增加，吞吐量往往增长到一个峰值后，然后下降，队列变长。
  分析：
      在C/S架构的系统中，吞吐量依赖每个部件的运行，系统地最慢点决定了整个系统的吞吐量，这个点我们称之为瓶颈。一般使用率最高的资源就是瓶颈（但也不总是这样，因为可能这种情况是某种资源正在处理多种请求），只要没有队列就没有瓶颈。
  LoadRunner监控：选择Windows资源监控器，对资源进行监控

队列：
  
   定义：处理请求排队
   评估点：服务器端进行评估
   表象：对资源的请求的速率大于资源的吞吐量。
   分析：当队列变长，请求不能被有效的处理，响应时间就会变慢。
 
响应时间：
   定义：从客户端发出请求到服务器端返回最后一个字节的时间
   评估点：通常从客户端来度量（LoadRunner通过事务来度量）
   表象：响应时间通常随着负载的增加而增加（虚拟用户数的增加，请求数的增加）
   分析：可以利用资源的队列的长度除以资源的吞吐量可以计算响应时间
   LoadRunenr：自定义事务是度量的关键，最后分析图中可以通过看平均事务响应时间图分析

Window性能监控原理

  操作系统本身时时采集系统资源如PhysicalDisk，Memory，CPU，NetWork等数据。缺省情况下，操作系统是通过注册表来收集系统资源。同时它也支持WMI（Window Management Infrastructure）收集数据，
  所以很多性能测试工具都宣称是通过无代理进行性能数据采集，在window平台上基本上所有的工具都可以做到（其他平台有些工具就不能达到loadrunner无代理方式的性能采集了），
 
   背景知识:在WMI出现之前，所有的 Windows管理工具都依赖于 Win32 应用程序编程接口（Application Programming Interfaces，APIs）来访问和管理 Windows 资源。因为在 WMI 之前，能够以编程方式访问 Windows 资源的惟一方法就是通过 Win32 API。这种情况使 Windows 系统管理员无法通过一种简便的方法利用常见的脚本语言来自动化常用的系统管理任务，因为大多数脚本语言都不能直接调用 Win32 API。通过提供一致的模型和框架，WMI 改变了这种情况 — 通过模型和框架，所有的 Windows 资源均被描述并公开给外界。最好的一点是，系统管理员可以使用 WMI 脚本库创建系统管理脚本，从而管理任何通过 WMI 公开的 Windows 资源！

例子代码：WMI脚本检索远程计算机上安装的物理内存量
strComputer = "pcl"

Set wbemServices = Getobject("winmgmts:\\" & strComputer)
Set wbemObjectSet = wbemServices.InstancesOf("Win32_LogicalMemoryConfiguration")

For Each wbemObject In wbemObjectSet
    Wscrīpt.Echo "Total Physical Memory (kb): " & wbemObject.TotalPhysicalMemory
Next

定位瓶颈：
   定位瓶颈是监控整个系统开始，如果某个环节限制了整个系统更快的执行才会存在瓶颈，即使系统中的一个或者多个使用超负荷，但是作为一个整体系统没有受到任何的影响，就不存在瓶颈。

瓶颈的产生的原因：主要是服务的请求数，请求的频率，请求的持续时间