在“监视服务器配置”中，要同时添加几个服务器可用逗号分隔服务器名或IP范围。如：255.255.255.0-255.255.255.5，server1,server2。

大家好，我是一家软件测试培训机构的市场部工作人员，从事这个行业将近2年的时间，由于是市场人员，所以对各家竞争对手的情况都比较了解，只想平心而论，具体不方便透露我所在的机构，也不会涉及其他培训机构的名字，免得竞争对手以为我在做广告。我只是想写一些软件测试行业内幕给真心想学软件测试的学生，说真的，在软件培训这块，选择真的大过努力，很多学生由于选择失误，一辈子的前途很容易就给毁了，这样的例子实在太多了！
先说说软件测试这个行业，有些人认为软件测试是从事低端工作的，薪资也很低，其实这样的看法是完全错误的，测试这个行业真的不错，但是不是你学了软件测试后一进公司就可以拿高薪，同样需要积累，我遇到过很多做测试的，地位很高，年薪20－40万，很正常，在大多数大公司，测试和开发的地位是一样的，而且测试升职更容易，因为竞争小。但是我在网上也确实是看到很多人说测试不好，是培训机构炒出来的，很大一部分原因是这些人在做开发，或者自己在小公司，所以才觉得测试没地位，其实完全不是这样的，而且居然有人说测试很简单，不用学，这些人就更不懂测试拉。
说说培训机构的选择，这才是重点，选择培训机构有很多误区，我列一下：
1、名气大、广告多就是好的培训机构－这是最大的误区，因为名气好不等于口碑好。培训是一锤子买卖，不是做回头客，无论培训质量是否好你都不会来培训第二次，所以名气和广告是不能作为培训机会好坏的依据的。
2、颁发证书，含金量高－这又是一个很大的误区，说白点，现在世面上的培训证书，什么劳动局、信息产业部（门）等等证书统统都是没用的，没有任何含金量，真不明白，政府机关为何如此重利忘义，很多学生都看中这个证书，培训出来之后找工作时才知道HR根本不理会这个的，但是现在很多垃圾培训机构还拿这张破纸大肆宣传，我要告诉大家的是：所有的证书都是没用的，学好技术自然走遍天下。
3、签订就业合同（协议），就业不成功退款多少多少－很多培训机构现在都这样说，但是一些培训机构（不包括所有）和你签的是100％推荐协议，你培训最好要选择100％保证就业协议，两者区别实在很大的，咨询的时候一定要问清楚，至于就业不成功退款也有很多条件限制的，什么叫“就业不成功”，我给你机会你自己放弃怎么算？所以要真正比较培训机构和你签的协议才能知道好坏。
4、我们的老师都是有多少多少年经验的－每个培训机构都这样说，但是是真是假你根本无法比较，你知道培训机构最大的成本之一是什么吗，好的培训机构最大的成本是老师，老师好不好直接关系到你将来的就业，在你无法比较老师好坏的情况下怎么办？有些人说试听，其实试听是没有用的，因为你根本听不懂。那怎么办呢，告诉你一个选择培训机构的秘诀：找培训了几个月的学员问问，口碑好才是真的好，记住，一定要主动找培训了3个月以上的学员，这样你才能真正知道培训效果怎么样。
    写了一些，不知道是否有错别字，我一气呵成的，肯能有语句不通的地方，请谅解，我好累啊，先写这面多，有不同意的地方可以交流，觉得写得是真实的就顶我。

　平均负载 系统正常状态下，最后60秒同步进程的

　　平均个数

　　冲突率 在以太网上监测到的每秒冲突数

　　进程/线程交换率 进程和线程之间每秒交换次数

　　CPU利用率 CPU占用率（％）

　　磁盘交换率 磁盘交换速率

　　接收包错误率 接收以太网数据包时每秒错误数

　　包输入率 每秒输入的以太网数据包数目

　　中断速率 CPU每秒处理的中断数

　　输出包错误率 发送以太网数据包时每秒错误数

　　包输入率 每秒输出的以太网数据包数目

　　读入内存页速率 物理内存中每秒读入内存页的数目

　　写出内存页速率 每秒从物理内存中写到页文件中的内存页数

　　目或者从物理内存中删掉的内存页数目

　　内存页交换速率 每秒写入内存页和从物理内存中读出页的个数

　　进程入交换率 交换区输入的进程数目

　　进程出交换率 交换区输出的进程数目

　　系统CPU利用率 系统的CPU占用率（％）

　　用户CPU利用率 用户模式下的CPU占用率（％）

　　磁盘阻塞 磁盘每秒阻塞的字节数

网络应用性能分析

　　网络应用性能分析的目的是准确展示网络带宽、延迟、负载和TCP端口的变化是如何影响用户的响应时间的。利用网络应用性能分析工具，例如Application Expert，能够发现应用的瓶颈，我们可知应用在网络上运行时在每个阶段发生的应用行为，在应用线程级分析应用的问题。可以解决多种问题：客户端是否对数据库服务器运行了不必要的请求？当服务器从客户端接受了一个查询，应用服务器是否花费了不可接受的时间联系数据库服务器？在投产前预测应用的响应时间；利用Application Expert调整应用在广域网上的性能；Application Expert能够让你快速、容易地仿真应用性能，根据最终用户在不同网络配置环境下的响应时间，用户可以根据自己的条件决定应用投产的网络环境。

　　网络应用性能监控

　　在系统试运行之后，需要及时准确地了解网络上正在发生什么事情；什么应用在运行，如何运行；多少PC正在访问LAN或WAN；哪些应用程序导致系统瓶颈或资源竞争，这时网络应用性能监控以及网络资源管理对系统的正常稳定运行是非常关键的。利用网络应用性能监控工具，可以达到事半功倍的效果，在这方面我们可以提供的工具是Network Vantage。通俗地讲，它主要用来分析关键应用程序的性能，定位问题的根源是在客户端、服务器、应用程序还是网络。在大多数情况下用户较关心的问题还有哪些应用程序占用大量带宽，哪些用户产生了最大的网络流量，这个工具同样能满足要求。

　　网络预测

　　考虑到系统未来发展的扩展性，预测网络流量的变化、网络结构的变化对用户系统的影响非常重要。根据规划数据进行预测并及时提供网络性能预测数据。我们利用网络预测分析容量规划工具PREDICTOR可以作到：设置服务水平、完成日网络容量规划、离线测试网络、网络失效和容量极限分析、完成日常故障诊断、预测网络设备迁移和网络设备升级对整个网络的影响。

　　从网络管理软件获取网络拓扑结构、从现有的流量监控软件获取流量信息（若没有这类软件可人工生成流量数据），这样可以得到现有网络的基本结构。在基本结构的基础上，可根据网络结构的变化、网络流量的变化生成报告和图表，说明这些变化是如何影响网络性能的。 PREDICTOR提供如下信息：根据预测的结果帮助用户及时升级网络，避免因关键设备超过利用阀值导致系统性能下降；哪个网络设备需要升级，这样可减少网络延迟、避免网络瓶颈；根据预测的结果避免不必要的网络升级。

　　应用在服务器上性能的测试

　　对于应用在服务器上性能的测试，可以采用工具监控，也可以使用系统本身的监控命令，例如Tuxedo中可以使用Top命令监控资源使用情况。实施测试的目的是实现服务器设备、服务器操作系统、数据库系统、应用在服务器上性能的全面监控，测试原理如下图。

图：应用在服务器上的性能测试原理图

UNIX资源监控指标和描述    监控指标 描述

测试结论：在新华社机房测试环境和内网测试环境中，100M带宽情况下，针对规定的各并发测试案例，系统能够承受并发用户数为200的负载压力，最大交易数/分钟达到78.73，运行基本稳定，但随着负载压力增大，系统性能有所衰减。

　　系统能够承受200并发用户数持续周期约8小时的疲劳压力，基本能够稳定运行。

　　通过对系统UNIX（Linux）、Oracle和Apache资源的监控，系统资源能够满足上述并发和疲劳性能需求，且系统硬件资源尚有较大利用余地。

　　当并发用户数超过200时，监控到HTTP 500、connect和超时错误，且Web服务器报内存溢出错误，系统应进一步提高性能，以支持更大并发用户数。

　　建议进一步优化软件系统，充分利用硬件资源，缩短交易响应时间。

　　疲劳强度与大数据量测试

　　疲劳测试是采用系统稳定运行情况下能够支持的最大并发用户数，持续执行一段时间业务，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。

　　疲劳强度测试可以采用工具自动化的方式进行测试，也可以手工编写程序测试，其中后者占的比例较大。

　　一般情况下以服务器能够正常稳定响应请求的最大并发用户数进行一定时间的疲劳测试，获取交易执行指标数据和系统资源监控数据。如出现错误导致测试不能成功执行，则及时调整测试指标，例如降低用户数、缩短测试周期等。还有一种情况的疲劳测试是对当前系统性能的评估，用系统正常业务情况下并发用户数为基础，进行一定时间的疲劳测试。

　　大数据量测试可以分为两种类型：针对某些系统存储、传输、统计、查询等业务进行大数据量的独立数据量测试；与压力性能测试、负载性能测试、疲劳性能测试相结合的综合数据量测试方案。大数据量测试的关键是测试数据的准备，可以依靠工具准备测试数据。

　　速度测试目前主要是针对关键有速度要求的业务进行手工测速度，可以在多次测试的基础上求平均值，可以和工具测得的响应时间等指标做对比分析。

　　应用在网络上性能的测试

　　应用在网络上性能的测试重点是利用成熟先进的自动化技术进行网络应用性能监控、网络应用性能分析和网络预测。

　模拟真实环境测试，有些软件，特别是面向大众的商品化软件，在测试时常常需要考察在真实环境中的表现。如测试杀毒软件的扫描速度时，硬盘上布置的不同类型文件的比例要尽量接近真实环境，这样测试出来的数据才有实际意义。

　　并发性能测试的种类与指标

　　并发性能测试的种类取决于并发性能测试工具监控的对象，以QALoad自动化负载测试工具为例。软件针对各种测试目标提供了DB2、DCOM、ODBC、ORACLE、NETLoad、Corba、QARun、SAP、SQLServer、Sybase、Telnet、TUXEDO、UNIFACE、WinSock、WWW、Java scrīpt等不同的监控对象，支持Windows和UNIX测试环境。

　　最关键的仍然是测试过程中对监控对象的灵活应用，例如目前三层结构的运行模式广泛使用，对中间件的并发性能测试作为问题被提到议事日程上来，许多系统都采用了国产中间件，选择Java scrīpt监控对象，手工编写脚本，可以达到测试目的。

　　采用自动化负载测试工具执行的并发性能测试，基本遵循的测试过程有：测试需求与测试内容，测试案例制定，测试环境准备，测试脚本录制、编写与调试，脚本分配、回放配置与加载策略，测试执行跟踪，结果分析与定位问题所在，测试报告与测试评估。

　　并发性能测试监控的对象不同，测试的主要指标也不相同，主要的测试指标包括交易处理性能指标和UNIX资源监控。其中，交易处理性能指标包括交易结果、每分钟交易数、交易响应时间（Min：最小服务器响应时间；Mean：平均服务器响应时间；Max：最大服务器响应时间；StdDev：事务处理服务器响应的偏差，值越大，偏差越大；Median：中值响应时间；90％：90％事务处理的服务器响应时间）、虚拟并发用户数。

　　应用实例：“新华社多媒体数据库 V1.0”性能测试

　　中国软件评测中心（CSTC）根据新华社技术局提出的《多媒体数据库（一期）性能测试需求》和GB/T 17544《软件包质量要求和测试》的国家标准，使用工业标准级负载测试工具对新华社使用的“新华社多媒体数据库 V1.0”进行了性能测试。

　　性能测试的目的是模拟多用户并发访问新华社多媒体数据库，执行关键检索业务，分析系统性能。

　　性能测试的重点是针对系统并发压力负载较大的主要检索业务，进行并发测试和疲劳测试，系统采用B/S运行模式。并发测试设计了特定时间段内分别在中文库、英文库、图片库中进行单检索词、多检索词以及变检索式、混合检索业务等并发测试案例。疲劳测试案例为在中文库中并发用户数200，进行测试周期约8小时的单检索词检索。在进行并发和疲劳测试的同时，监测的测试指标包括交易处理性能以及UNIX（Linux）、Oracle、Apache资源等。

目前，大多数公司企业需要支持成百上千名用户，各类应用环境以及由不同供应商提供的元件组装起来的复杂产品，难以预知的用户负载和愈来愈复杂的应用程序，使公司担忧会发生投放性能差、用户遭受反应慢、系统失灵等问题。其结果就是导致公司收益的损失。

　　如何模拟实际情况呢? 找若干台电脑和同样数目的操作人员在同一时刻进行操作,然后拿秒表记录下反应时间？ 这样的手工作坊式的测试方法不切实际，且无法捕捉程序内部变化情况,这样就需要压力测试工具的辅助。

　　测试的基本策略是自动负载测试，通过在一台或几台PC机上模拟成百或上千的虚拟用户同时执行业务的情景，对应用程序进行测试，同时记录下每一事务处理的时间、中间件服务器峰值数据、数据库状态等。通过可重复的、真实的测试能够彻底地度量应用的可扩展性和性能，确定问题所在以及优化系统性能。预先知道了系统的承受力,就为最终用户规划整个运行环境的配置提供了有力的依据。

    并发性能测试前的准备工作

　　测试环境：配置测试环境是测试实施的一个重要阶段，测试环境的适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。

　　一个充分准备好的测试环境有三个优点：一个稳定、可重复的测试环境，能够保证测试结果的正确；保证达到测试执行的技术需求；保证得到正确的、可重复的以及易理解的测试结果。

　　测试工具：并发性能测试是在客户端执行的黑盒测试，一般不采用手工方式，而是利用工具采用自动化方式进行。目前，成熟的并发性能测试工具有很多，选择的依据主要是测试需求和性能价格比。著名的并发性能测试工具有QALoad、LoadRunner、Benchmark Factory和Webstress等。这些测试工具都是自动化负载测试工具，通过可重复的、真实的测试，能够彻底地度量应用的可扩展性和性能，可以在整个开发生命周期、跨越多种平台、自动执行测试任务，可以模拟成百上千的用户并发执行关键业务而完成对应用程序的测试。

　　测试数据：在初始的测试环境中需要输入一些适当的测试数据，目的是识别数据状态并且验证用于测试的测试案例，在正式的测试开始以前对测试案例进行调试，将正式测试开始时的错误降到最低。在测试进行到关键过程环节时，非常有必要进行数据状态的备份。制造初始数据意味着将合适的数据存储下来，需要的时候恢复它，初始数据提供了一个基线用来评估测试执行的结果。

　　在测试正式执行时，还需要准备业务测试数据，比如测试并发查询业务，那么要求对应的数据库和表中有相当的数据量以及数据的种类应能覆盖全部业务。

性能测试在软件的质量保证中起着重要的作用，它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。

　　应用在客户端性能的测试

　　应用在客户端性能测试的目的是考察客户端应用的性能，测试的入口是客户端。它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等，其中并发性能测试是重点。

　　并发性能测试是重点

    并发性能测试的过程是一个负载测试和压力测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。负载测试（Load Testing）是确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用，从而来确定能够接收的性能过程。压力测试（Stress Testing）是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

　　并发性能测试的目的主要体现在三个方面：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；当扩展应用程序的功能或者新的应用程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的用户负载，以预测系统的未来性能；通过模拟成百上千个用户，重复执行和运行测试，可以确认性能瓶颈并优化和调整应用，目的在于寻找到瓶颈问题。

　　当一家企业自己组织力量或委托软件公司代为开发一套应用系统的时候,尤其是以后在生产环境中实际使用起来,用户往往会产生疑问,这套系统能不能承受大量的并发用户同时访问? 这类问题最常见于采用联机事务处理(OLTP)方式数据库应用、Web浏览和视频点播等系统。这种问题的解决要借助于科学的软件测试手段和先进的测试工具。

　　举例说明：电信计费软件

　　众所周知,每月20日左右是市话交费的高峰期，全市几千个收费网点同时启动。收费过程一般分为两步,首先要根据用户提出的电话号码来查询出其当月产生费用,然后收取现金并将此用户修改为已交费状态。一个用户看起来简单的两个步骤,但当成百上千的终端，同时执行这样的操作时，情况就大不一样了,如此众多的交易同时发生,对应用程序本身、操作系统、中心数据库服务器、中间件服务器、网络设备的承受力都是一个严峻的考验。决策者不可能在发生问题后才考虑系统的承受力, 预见软件的并发承受力, 这是在软件测试阶段就应该解决的问题。

如果在监视网络中，源计算机和目标计算机之间有防火墙，则必须配置防火墙以
便允许网络数据包到达它们的目的地。
1: 如果使用的是 TCP 协议，保护目标计算机的防火墙不应该阻塞传出的
ICMP_TIMEEXCEEDED 包（从该计算机发送到防火墙以外的包）。另外，保护
源计算机的防火墙应该允许 ICMP_TIMEEXCEEDED 包传入，以及 TCP 包传出。
2:如果使用的是 ICMP 协议，则目标计算机的防火墙不应该阻塞传入的
ICMP_ECHO_REQUEST 包或传出的 ICMP_ECHO_REPLY 和
ICMP_ECHO_TIMEEXCEEDED 包。另外，保护源计算机的防火墙应该允许
ICMP_ECHO_REPLY 和 ICMP_ECHO_TIMEEXCEEDED 包传入，以及
ICMP_ECHO_REQUEST 包传出。
3:如果使用的是 UDP 协议，应确保 UDP 协议可以从源计算机访问目标计算机。目
标计算机的防火墙不应该阻塞传出的 ICMP_DEST_UNREACHABLE 和
ICMP_ECHO_TIMEEXCEEDED 包。另外，保护源计算机的防火墙应该允许
ICMP_DEST_UNREACHABLE 和 ICMP_ECHO_TIMEEXCEEDED 包传入。
注意：Controller 计算机和源计算机之间有防火墙时，要运行网络延迟监视器，
必须配置 LoadRunner 代理、MI 侦听器以及跨防火墙监视的网络监视器。

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服务同时建立起来的最大连接数。

内存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 服务器响应请求比较快，否则可能是服务器系统内存短缺引起（ 也可能是缓存太大，导致系统内存太少）。

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

接触LR有些时间了，也做过几个大型政府OA的测试，一直有一些想法想法和大家交流。
LR做压力负载是一个很少的工具，目前在世界上的市场份额也是最多的，大约在70%左右，次之的是QA_load。
压力负载测试最重要的是环境的配置，一定要模拟真实的环境，否则得出的结果会和真实情况有很大的出入。
比如数据库查询时，库里的数据一定要多，也就是所说的大数据量测试。
环境配置根据不同的系统存在很大差异，但是也有一定的规律可循，或者说一般也有一些通用的原则：
1、并发用户数一般是在线用户数的2%~3%，需要注意的是使用用户数、在线用户数和并发用户数的却别；
2、事务响应时间：3秒之内（非常好）、3-5秒（一般）、5-8秒（免强接受）、8秒以内（用户不能接受），一般都遵循3、5、8原则；
3、每秒事务数：80%的事务在20%的时间内完成（一年安160天算，一天8小时算），一般遵循80-20原则；
4、服务器在受压情况下，cpu最佳占用率为60%~80%，多了cpu受不了，少了资源浪费；
5、服务器在不受压情况下，内存占用率最佳为25%，多了影响服务器性能；
压力负载测试中也需要注意：
1、注意区别内存泄露和动态内存分配问题；
2、注意压力端和服务器端的网络流量，一般来说目前的网络不会是系统的瓶颈，但是也需要注意；
3、单机的压力用户数不要过多，否则会影响测试结果，最好不要超过300；
4、分不同的组来运行不同的事务脚本，应真实的模拟系统情况；

Secure socket layer(SSL)协议最初由Netscape企业发展，现已成为网络用来鉴别网站 和网页浏览者身份，以及在浏览器使用者及网页服务器之间进行加密通讯的全球化标准 。由于SSL技术已建立到所有主要的浏览器和WEB服务器程序中，因此，仅需安装数字证书，或服务器证书就可以激活服务器功能了 。对于Web信息传输通道的机密性及完整性，SSL是最佳的解决方案，目前所有的浏览器和Web服务器都支持SSL，采用SSL 在技术上已经很成熟，互联网的安全敏感数据几乎都是由SSL通道传输的。

采用SSL技术和数字签名技术保证邮件的安全性，为了满足企业用户保护商业秘密的需求 ，提供了完善邮件加密和认证功能，采用SSL技术对邮件的存储和传输实施加密，保证邮件不被窃取和篡改；并且提供数字签名技术， 以保证邮件的真实性。系统提供了从普通级到绝密级等多种保密等级，以满足不同环境下的保密需求。SSL协议是因特网通信标准，用 来提供两个应用之间通信的保密，可信和身份认证。SSL技术一般采用公开密钥技术，能够提供：信息加密服务，信息完整性服务，相 互认证服务这三项服务。

下面，我们将从通信量分析、主动攻击、重放攻击、密码组回滚攻击以及中间人攻击这五种常见的安全攻击入手，初步分析SSL的抵御 攻击能力。
通信量分析
如果常规的攻击失败，密码破译专家会转向使用更复杂的攻击。通信量分析是另外一种被动攻击，但它经常是恶意攻击，因此值得一提。 通信量分析的目标在于，通过检查包中未加密的域及属性，以获得受保护会话的机密信息。例如，通过检查未加密的源和目标的IP地址 （甚至TCP端口号），或者检查网络通信流，一个通信量分析专家可以确定通信各方的通信内容，使用的服务类型，有时甚至还可以获 得有关商业或个儿关系的信息。实际上，用户大都认为通信量分析的威胁相对来说是无害的，因此SSL不会试图阻止这种攻击。忽略通 信量分析看来是一种可行的设计方案。

然而在SSL体系结构中，通信量分析仍会造成一些巧妙的威胁。Bennet Yee已经指出，检查密文的长度会暴露出有关SSL或被SSL加密的网站通信中用到的URL请求的信息【Yee96】。当一个W eb浏览器通过加密传输（如SSL）连接到一台Web服务器时，包含有URL信息的GET请求会以加密方式进行传输。严格来说， 浏览器要下载哪一个页面，这种信息是保密的——显然，具有URL方面的知识，对于一个想下载整个网站的人来说，这已经足够了—— 而且，通信量分析可以获得Web服务器的身份信息，请求的URL长度，以及从Web服务器所返回的html数据的长度。这个漏洞 往往使得窃听者能够发现用户访问了哪些Web页面。

上述弱点之所以出现，是因为密文长度暴露了明文的长度。SSL在块加密模式中支持随机填充，而在流加密模式中却不支持。我们相信 ，对于所有的加密模式，SSL将会在最小程度上支持任意长度填充的使用，而且会仔细地考虑它在特定应用程序中的需求。

主动攻击
SSL能抵御主动攻击以安全地保护机密数据，这一点非常重要。当然，所使用的加密算法应该在被选择明文∕被选择密文攻击下是安全 的，但这对于加密算法来说还不够。IETF的IPSEC工作组的最近研究表明，即使所使用的密码强度足够，在记录层上精明的主动 攻击仍能打破系统的保密性。SSL 3.0 的记录层能抵御这些强有力的攻击：更进一步，为何这些攻击会被阻止，值得我们讨论。

IPSEC中的一个重要的主动攻击是Bellovin的剪贴攻击。回想起来，要获得保密性，光对链接进行加密是不够的——接收端 也必须防止敏感数据在无意中被泄露出来。剪贴攻击的攻击方式就是谋求接收端的信任，使之对敏感数据进行解密并将这些数据泄露给它 们。
SSL 3.0能够阻止剪贴攻击。阻止这种攻击的一种局部性防御策略是为每一个不同的上下文使用独立的会话密钥，这样便能在不同的连接之 间，以及连接的不同方向之间阻止剪贴操作。SSL已经为每个连接方向使用了独立的密钥。但是，这种机制无法阻止传输中一个方向上 的剪贴操作。应用最广泛的防御策略是在所有加密包上使用强大的认证机制，以阻止敌方对密文数据的修改。SSL记录层确实采用了这 种防御策略，因此剪贴操作被完全阻止住了。
另一种主动攻击是短块攻击，它主要针对IPSEC。这种攻击适用于最后的报文块包含一个一字节长的明文并且报文块剩余部分由随机 数填充的情况。在SSL上并没有明显的短块攻击。SSL记录层格式与以前的IPSEC格式相当类似，这种格式容易遭到攻击，因此 可以想象，修改性攻击会对SSL产生威胁。但是，无论如何，由标准SSL加密的Web服务器基本上不会受到短块攻击的威胁，因为 这些服务器不会经常对短块进行加密。（但要注意，由SSL加密的telnet客户端必须得到特殊的保护，以防止短块攻击，因为每 一次按键在传送时都是一字节长的数据包。）

重放攻击
光靠使用报文鉴别码（MAC）不能防止对方重复发送过时的信息包。SSL通过在生成MAC的数据中加入隐藏的序列号，来防止重放 攻击。这种机制也可以防止被耽搁的，被重新排序的，或者是被删除数据的干扰。

1：注意：要运行网络监视器，您在 Windows 源计算机上必须拥有管理员权限（除非您使用的是 ICMP 协议）。
2：要启用网络监视，必须在源计算机上（运行Vsuser的机器）安装 LoadRunner 代理。不必在目标计算机（服务器）上安装 LoadRunner 代理。
3：如果目标计算机是“本地主机”，请输入本地计算机的名称而不是“localhost”。
4：要查看网络路径中每个节点的 DNS 名以及它的 IP 地址，请选择“启用网络节点显示（按 DNS 名）”。注意，选中此选项将降低网络监视器的速度。

事务是在脚本中定义的某个操作，而点击是在测试中产生的http请求。

例如，我定义了一个提交form的事务，我关心的也就是这个提交操作的数量与分值及响应时间的关系。而实际上这个form提交可能产生多个http请求。首先提交form本身有一次http请求，如果此请求被服务器端接受，则要转向到结果页面的第一个页面，又是一次http请求，如果这个页面中含有图片的话，那么每个图片都需要通过一个http连接来下载。

所以：

平均每个事务产生的点击数

 ＝ 事务的数量＋事务的数量×事务成功概率＋事务的数量×事务成功概率×平均每个页面中含有的图片数

 ＝ 事务的数量×（1＋平均事务成功概率×（1＋平均每个页面含有的图片数））

1、如果在场景中执行一个脚本（没有集合点），100个用户，选择load all users simultaneously，实际就是100用户在同时作这件事情，但并不是同时点一个按钮？

2、如果在场景中执行一个脚本（没有集合点），100个用户，选择10秒加10个用户，实际最多是少于100用户在同时作这件事情？

3、如果在场景中执行一个脚本（有集合点），100个用户，选择load all users simultaneously，大家都同时集合起来，点那个按钮？

插入集合点会不会影响事务的相应时间？
1.我决定是的。所谓load all users simultaneously只是lr同时在本机启动了Vusers，由于各个user的响应不同，对于服务器并不是同时在施加负载。这种情况只能叫做100个用户在线

2.这个取决于您定义的脚本执行时间，如果脚本执行时间足够长，大于100秒，那么到100秒以后，就和情况1一样了，也是100个用户在线了。

3.定义集合点是保证所用用户同时点按钮的前提，这和load all users simultaneously关系不是很大，因为集合点还有个timeout的问题，如果所有用户都没有timeout，那么可以认为所有用户同时点了那个按钮。

网络时间是从发出第一个http请求到收到ACK的时间。
服务器时间是从收到ACK到第一个字节返回的时间。
ACK是TCP首部中的确认标志，对已接受到的TCP报文进行确认。

备注：
英文缩写: ACK (ACKnowledge Character）
中文译名: 确认字符
分　　类: 传输与接入
解　　释: 在数据通信传输中，接收站发给发送站的一种传输控制字符。它表示确认发来的数据已经接受无误

一、Apache上的设置

打开<Apache Installation>\conf\httpd.conf，进行如下修改：

1、  设置允许查看Apache运行状态的主机
#

# Allow server status reports, with the URL of http://servername/server-status

# Change the ".your-domain.com" to match your domain to enable.

#

#取消一下代码前面的注释符号“#”，并且设置Order（顺序）为允许优先

<Location /server-status>

    SetHandler                                  server-status

    Order                                        allow,deny

    Deny from                                 nothing

    Allow from                                all

</Location>

这样改变以后重新启动Apache在浏览器中输入http://servername/server-status就可以看到Apache运行时的信息，而输入http://servername/server-status?auto就会看到如下信息：

Total Accesses: 124 Total kBytes: 444 CPULoad: 3.32432 Uptime: 37 ReqPerSec: 3.35135 BytesPerSec: 12288 BytesPerReq: 3666.58 BusyWorkers: 1 IdleWorkers: 7 Scoreboard: ____W___.........................

看到这样的信息就表示修改成功，这样就可以使用LoadRunner监视Apache了。

以下两步跟使用LoadRunner监视Apache无关，可以跳过不看。

2、  改变Apache的设置，打开详细状态开关；

#

# ExtendedStatus controls whether Apache will generate "full" status

# information (ExtendedStatus On) or just basic information (ExtendedStatus

# Off) when the "server-status" handler is called. The default is Off.

#

#取消了下面一行前面的注释符号“#”

ExtendedStatus On

3、  有用的设置，查看各模块信息

#

# Allow remote server configuration reports, with the URL of

#  http://servername/server-info (requires that mod_info.c be loaded).

# Change the ".example.com" to match your domain to enable.

#

#取消一下代码前面的注释符号“#”，并且设置Order（顺序）为允许优先

<Location /server-info>

    SetHandler                                  server-info

    Order                                         allow,deny

    Deny from                                  nothing

    Allow from                                 all

</Location>

二、LoadRunner上的设置

经过以上第一项设置以后就可以使用LoadRunner监控Apache的运行情况了，在LoadRunner可用的监视器中双击Web Server Resource Graphs下的Apache节点，然后在右边对应的窗口中添加Apache所在主机的IP地址，并且加入计数器后单击OK，这样就可以在LoadRunner中实时显示Apache的运行状态信息了。
注意：您可能收到如下消息【Monitor name :Apache. Parsing error, cannot find token: BusyServers. Measurement: BusyServers|192.168.0.186. Hints: 1) Such a measurement does not exist, or the html page may be different from the supported one. 2) Try to replace the Apache.cfg with appropriate Apache_<version>.cfg file in <Installation>\dat\monitors and rerun the application (entry point: CApacheMeasurement::NewData).      [MsgId: MMSG-47479]】，这是由于要监视Apache的版本提供的计数器与LoadRunner默认的计数器不一致导致的。此时建议先关闭Controller，打开<Installation>\dat\monitors下的apache.cfg文件（其它文件名类似Apache_<version>.cfg的是Apache监视配置的备份，只有apache.cfg是生效的）：
1、  修改Counter0=IdleServers为Counter0=IdleWorkers，同时修改注释信息Label0=#Idle Servers (Apache)为Label0=#Idle Workers (Apache)，描述信息也建议修改；
2、  修改Counter4=BusyServers为Counter4=BusyWorkers，同时修改注释信息Label4=#Busy Servers (Apache)为Label4=#Busy Workers (Apache) ，描述信息也建议修改。
然后保存并关闭该文件，重新打开Controller并添加计数器，这样监视就正常了。

最近在论坛上的一些朋友问脚本方面的问题，比如用lr的winsock协议录制的脚本遇回放过程中遇到如下错误
Action.c(20): Error : callConnect - Can't assign requested address. Error code : 10049.
Action.c(20): Error : Timeout expired while trying to connect. Error code : 9017.
这里的10049是udp协议错误，是脚本没有和服务器同步，这说明什么问题呢。下边我用一个协议进行分析，来看看到底是什么问题，
smtp协议分析：
1.SMTP工作方式有两种情况：一是电子邮件从客户机传输到服务器；二是从某一个服务器传输到另一个服务器.
    2.SMTP是个请求/响应协议，命令和响应都是基于ASCII文本，并以CR和LF符结束。响应包括一个表示返回状态的三位数字代码.
    3.SMTP在TCP协议25号端口监听连接请求
    4.连接和发送过程：
a.建立TCP连接
b.客户端发送HELO命令以标识发件人自己的身份，然后客户端发送MAIL命令服务器端正希望以OK作为响应，表明准备接收
c.客户端发送RCPT命令，以标识该电子邮件的计划接收人，可以有多个RCPT行服务器端则表示是否愿意为收件人接受邮件
d.协商结束，发送邮件，用命令DATA发送
e.以.表示结束输入内容一起发送出去
f.结束此次发送，用QUIT命令退出。
5.另外两个命令：
VRFY---用于验证给定的用户邮箱是否存在，以及接收关于该用户的详细信息。
EXPN---用于扩充邮件列表。
6.邮件路由过程：
SMTP服务器基于‘域名服务DNS中计划收件人的域名来路由电子邮件。SMTP服务器基于DNS中的MX记录来路由电子邮件，MX记录注册了域名和相关的SMTP中继主机，属于该域的电子邮件都应向该主机发送。
若SMTP服务器mail.withub.org收到一封信要发到pcl@withub.org
a.Sendmail请求DNS给出主机withub.org的CNAME记录，如有，假若CNAME到mail.withub.org，则再次请求mail.withub.org的CNAME记录，直到没有为止. 
b.假定被CNAME到mail.withub.org,然后sendmail请求@withub.org域的DNS给出mail.withub.org的MX记录，
shmail MX 5 mail.withub.org
    10 shmail2.withub.org
    c. Sendmail最后请求DNS给出shmail.withub.org的A记录，即IP地址，若返回值为1.2.3.4
    d. Sendmail与1.2.3.4连接，传送这封给pcl@withub.org的信到1.2.3.4这台服务器的SMTP后台程序
这里是协议的一个解析过程，我们要看看，利用lr录制脚本后然后回放，录制的过程中mail.withub.org返回客户端服务器上有多少给用户的邮件，lr把这个数字保存下来，最为下次回放的时候对比。当你第二次回放的时候，lr模拟客户端发送请求，这时候服务器上没有了新邮件，返回可能是0,lr把这个返回值和当时录制的脚本保存的返回值进行对比（那个时候可能服务器上有3个新的邮件，服务器返回的值是3），明显这个值是动态变化的。你的脚本如果没有经过修改，肯定是回返不成功的。
     那么上边提到的错误信息，同样的道理，我们要分析一下到底是什么问题，从协议上分析，从系统环境上分析。
解决方法，动态关联
    1.用同样的用户操作同样的步骤两次，然后用lr工具wdiff进行脚本对比，找出不同的地方！
    2.用lr自动关联
    3.手工关联，找到要替换的动态数据进行替换