性能测试指标介绍
第一页 | 第二页
TPC-C
作为一家非盈利性机构，事务处理性能委员会（TPC）负责定义诸如TPC-C、TPC-H和TPC-W基准测试之类的事务处理与数据库性能基准测试，并依据这些基准测试项目发布客观性能数据。TPC基准测试采用极为严格的运行环境，并且必须在独立审计机构监督下进行。委员会成员包括大多数主要数据库产品厂商以及服务器硬件系统供应商。
相关企业参与TPC基准测试以期在规定运行环境中获得客观性能验证，并通过应用测试过程中所使用的技术开发出更加强健且更具伸缩性的软件产品及硬件设备。
TPC-C是一种旨在衡量联机事务处理（OLTP）系统性能与可伸缩性的行业标准基准测试项目。这种基准测试项目将对包括查询、更新及队列式小批量事务在内的广泛数据库功能进行测试。许多IT专业人员将TPC-C视为衡量“真实”OLTP系统性能的有效指示器。
TPC-C基准测试针对一种模拟订单录入与销售环境测量每分钟商业事务（tpmC）吞吐量。特别值得一提的是，它将专门测量系统在同时执行其它四种事务类型（如支付、订单状态更新、交付及证券级变更）时每分钟所生成的新增订单事务数量。独立审计机构将负责对基准测试结果进行公证，同时，TPC将出据一份全面彻底的测试报告。这份测试报告可以从TPC Web站点(https://www.doczj.com/doc/1414775130.html,)上获得。
tpmC定义: TPC-C的吞吐量，按有效TPC-C配置期间每分钟处理的平均交易次数测量，至少要运行12分钟。
1．TPC-C规范概要
TPC-C是专门针对联机交易处理系统（OLTP系统）的，一般情况下我们也把这类系统称为业务处理系统。TPC-C测试规范中模拟了一个比较复杂并具有代表意义的OLTP应用环境:假设有一个大型商品批发商，它拥有若干个分布在不同区域的商品库；每个仓库负责为10个销售点供货；每个销售点为3000个客户提供服务；每个客户平均一个订单有10项产品;所有订单中约1%的产品在其直接所属的仓库中没有存货，需要由其他区域的仓库来供货。
该系统需要处理的交易为以下几种：
?New-Order：客户输入一笔新的订货交易；
?Payment:更新客户账户余额以反映其支付状况;
?Delivery:发货(模拟批处理交易);
?Order-Status:查询客户最近交易的状态；
?Stock-Level:查询仓库库存状况，以便能够及时补货。
对于前四种类型的交易，要求响应时间在5秒以内；对于库存状况查询交易，要求响应时间在20秒以内。逻辑结构图：
流程图：
2．评测指标
TPC-C测试规范经过两年的研制，于1992年7月发布。几乎所有在OLTP市场提供软硬件平台的厂商都发布了相应的TPC-C测试结果，随着计算机技术的不断发展，这些测试结果也在不断刷新。
TPC-C的测试结果主要有两个指标：
● 流量指标(Throughput，简称tpmC)
按照TPC的定义，流量指标描述了系统在执行Payment、Order-status、Delivery、Stock-Level这四种交易的同时，每分钟可以处理多少个New-Order交易。所有交易的响应时间必须满足TPC-C测试规范的要求。
流量指标值越大越好！
● 性价比(Price/Performance，简称Price/tpmC)
即测试系统价格（指在美国的报价）与流量指标的比值。
性价比越小越好！
3．结果发布
各厂商的TPC-C测试结果都按TPC组织规定的两种形式发布：测试结果概要(Executive Summary)和详细测试报告(Full Disclosure Report)。测试结果概要中描述了主要的测试指标、测试环境示意图以及完整的系统配置与报价，而详细测试报告中除了包含上述内容外，还详细说明了整个测试环境的设置与测试过程。
P690 tpmC测试值：76,389,839.00
$/tpmC：831.00
美国美金报价：6,349,223.0
CPU数：32
数据库：IBM DB2 UDB 8.1
操作系统：AIX 5L V5.2
中间件：TUXEDO 8.0
测试日期：2003.6.30
P690 TPC-C测试的配置：
1．后台：1 x eServer pSeries 690 with 32 x 1.7GHz POWER4+ processors with 128MB L3 cache per MCM (total of four MCMs), 512GB memory
2．前端：30 x eServer pSeries 630 Model 6E4 each with 4 x 1.0GHz POWER4 CPUs with 32MB L3 cache, 16GB memory
SPECweb:
SPECweb96: 在SPECweb96基准测试程序上实现的每秒钟超文本传输协议（HTTP）操作最多次数，响应时间无明显退化。
SPECweb99: 接入数，网络服务器可用预先确定的工作量支持的同时接入数。SPECweb99检测设备模拟客户通过慢Internet联接，向网络服务器发送HTTP工作量请求。
SPECweb99 测试Web服务器运行状况
SPECweb99 是由标准性能评估组织（SPEC）开发的Web服务器基准测试。它测量满足特定吞吐量和客户请求响应速率要求的WEB服务器的最大并发连接数量。并发连接的合计波特率在320 Kbps到
400Kbps范围内，则满足相应规范。
SPECweb99 在一台称为主客户端的机器上运行，这台机器上包含有允许用户加载特定负载请求的配置文件。主客户端也要处理在客户端和服务器或测试中的系统（SUT）之间的传输协调问题。客户端通过许多子进程／线程生成独立HTTP请求流，仿真足够的负载发送给SUT。图二表示客户端／服务器的层次关系。
图：典型的SPECweb99实验环境
在这个测试中，客户端向测试中的服务器发送请求数据。测试规范要求客户端和服务器之间的连接不能使用片段大小大于1460比特的TCP协议。因此，每一个客户端读取1460比特或更少数据块的响应。
测试中使用两种类型的负载量：
静态负载. 静态负载具有四种类型的文件。最小的文件的增幅为0.1KB，第二种文件类型的增幅为1KB，最后两种类型的文件的增幅为10KB和100KB。每一个目录包含每种类型9个文件共36个文件。
目标请求的文件类型在各类型中分散使用。在每一类中的9个文件中又进行二次分布。最终目标文件混合为：
35％的请求文件小于1 KB
50％的请求文件小于10 KB
14％的请求文件小于100 KB，但是大于或等于10 KB
1％的请求文件小于1000 KB，但是大于或等于100 KB
动态负载.动态负载是基于广告和用户注册。共有四种在SPECweb99中使用的请求内容类型，分别是标准动态取操作、动态随机取操作、动态发送操作和客户图形接口动态取操作。标准动态取操作和客户图形接口动态取操作表现web服务器的简单广告轮转特性。带有广告轮转的动态取操作追踪用户和用户选择，所以广告可以由不同的方式来定制。最终，动态发布实施一个用户注册在相应的网站上。
P690 SPECweb99测试值：21,000
Web服务器：Zeus 4.0
操作系统：AIX 5L V5.1 (64-bit)
CPU数：16
测试日期：2001-10-1
测试配置：16 x 1.3GHz POWER-4 Processors w/1440KB unified on chip L2 cache, 192GB memory, 32 x 32 IBM Gigabit Ethernet-SX PCI controllers, 32 x Gigabit Ethernet network (1 Gigabit/sec ), 96 x Clients (4 x 375MHz POWER3-II, RS/6000 44P-270), Requested Connections = 21000, Max Fileset Size = 67319.6MB
P650 SPECweb99测试值：12,400
Web服务器：Zeus 4.1r3
操作系统：AIX 5L V5.2 (64-bit)
CPU数：8
测试日期：2002-10-1
测试配置：8 x 1.45GHz POWER4+ processors w/1.5MB(I+D) unified on chip L2 cache, 32MB unified off chip/SCM L3 cache, 64GB memory, 8 x Gigabit Ethernet-SX PCI-X controllers, 8 x Gigabit Ethernet network (1 Gigabit/sec ), 48 x Clients (6 x 668MHz RS64-IV, pSeries 620 Model 6F1), Requested Connections = 12400, Max Fileset Size = 39801.28MB
p630 SPECweb99测试值：6,895
Web服务器：Zeus 4.2r1
操作系统：AIX 5L V5.2(64-bit)
CPU数：4
测试日期：2003-2-1
测试配置：4 x 1450MHz POWER4+ Processors w/1536KB(I+D) unified on chip L2 cache, 8MB unified (off chip)/SCM L3 cache, 32GB memory, 4 x Gigabit Ethernet-SX PCI-X controllers, 4 x Gigabit Ethernet networks (1 Gigabit/sec ), 24 x Clients (4 x 375MHz POWER3-II, pSeries 640 Model B80), Requested Connections = 6900, Max Fileset Size = 22199.12MB
NotesBench:
NotesBench是测试各种不同Lotus Notes方面的驱动程序。目的是执行自定义工作量教本中的命令，模拟客户机的操作。NotesBench测试“仅测试邮件”和“测试邮件和数据库”。所有已经公布的IBM结果均为“仅测试邮件工作量”。
p680 NotesBench测试值：150,197
用户数：108,000
平均反应时间：0.584秒
Domino服务器版本：5.06a
操作系统：AIX 4.3.3
CPU数：4
测试日期：2001.11.20
测试配置：IBM eServer pSeries 680 (24*RS64 IV/600MHz; 96GB RAM, 30 Partitions)
性能测试指标介绍 第一页 | 第二页 TPC-C 作为一家非盈利性机构，事务处理性能委员会（TPC）负责定义诸如TPC-C、TPC-H和TPC-W基准测试之类的事务处理与数据库性能基准测试，并依据这些基准测试项目发布客观性能数据。TPC基准测试采用极为严格的运行环境，并且必须在独立审计机构监督下进行。委员会成员包括大多数主要数据库产品厂商以及服务器硬件系统供应商。 相关企业参与TPC基准测试以期在规定运行环境中获得客观性能验证，并通过应用测试过程中所使用的技术开发出更加强健且更具伸缩性的软件产品及硬件设备。 TPC-C是一种旨在衡量联机事务处理（OLTP）系统性能与可伸缩性的行业标准基准测试项目。这种基准测试项目将对包括查询、更新及队列式小批量事务在内的广泛数据库功能进行测试。许多IT专业人员将TPC-C视为衡量“真实”OLTP系统性能的有效指示器。 TPC-C基准测试针对一种模拟订单录入与销售环境测量每分钟商业事务（tpmC）吞吐量。特别值得一提的是，它将专门测量系统在同时执行其它四种事务类型（如支付、订单状态更新、交付及证券级变更）时每分钟所生成的新增订单事务数量。独立审计机构将负责对基准测试结果进行公证，同时，TPC将出据一份全面彻底的测试报告。这份测试报告可以从TPC Web站点(https://www.doczj.com/doc/1414775130.html,)上获得。 tpmC定义: TPC-C的吞吐量，按有效TPC-C配置期间每分钟处理的平均交易次数测量，至少要运行12分钟。 1．TPC-C规范概要 TPC-C是专门针对联机交易处理系统（OLTP系统）的，一般情况下我们也把这类系统称为业务处理系统。TPC-C测试规范中模拟了一个比较复杂并具有代表意义的OLTP应用环境:假设有一个大型商品批发商，它拥有若干个分布在不同区域的商品库；每个仓库负责为10个销售点供货；每个销售点为3000个客户提供服务；每个客户平均一个订单有10项产品;所有订单中约1%的产品在其直接所属的仓库中没有存货，需要由其他区域的仓库来供货。 该系统需要处理的交易为以下几种： ?New-Order：客户输入一笔新的订货交易； ?Payment:更新客户账户余额以反映其支付状况; ?Delivery:发货(模拟批处理交易); ?Order-Status:查询客户最近交易的状态； ?Stock-Level:查询仓库库存状况，以便能够及时补货。 对于前四种类型的交易，要求响应时间在5秒以内；对于库存状况查询交易，要求响应时间在20秒以内。逻辑结构图：
Web性能测试的部分概况一般来说，一个Web请求的处理包括以下步骤： （1）客户发送请求 （2）web server 接受到请求，进行处理； （3）web server 向DB获取数据； （4）web server生成用户的object(页面)，返回给用户。给客户发送请求开始到最后一个字节的时间称为响应时间（第三步不包括在每次请求处理中）。 1.事务（Transaction） 在web性能测试中，一个事务表示一个“从用户发送请求->web server接受到请求，进行处理-> web server向DB获取数据->生成用户的object(页面)，返回给用户”的过程，一般的响应时间都是针对事务而言的。 2.请求响应时间 请求响应时间指的是从客户端发起的一个请求开始，到客户端接收到从服务器端返回的响应结束，这个过程所耗费的时间，在某些工具中，响应通常会称为“TTLB”，即"time to last byte"，意思是从发起一个请求开始，到客户端接收到最后一个字节的响应所耗费的时间，响应时间的单位一般为“秒”或者“毫秒”。一个公式可以表示：响应时间＝网络响应时间+应用程序响应时间。标准可参考国外的3/5/10原则： （1）在3秒钟之内，页面给予用户响应并有所显示，可认为是“很不错的”； （2）在3~5秒钟内，页面给予用户响应并有所显示，可认为是“好的”；
（3）在5~10秒钟内，页面给予用户响应并有所显示，可认为是“勉强接受的”； （4）超过10秒就让人有点不耐烦了，用户很可能不会继续等待下去； 3、事务响应时间 事务可能由一系列请求组成,事务的响应时间主要是针对用户而言,属于宏观上的概念，是为了向用户说明业务响应时间而提出的.例如:跨行取款事务的响应时间就是由一系列的请求组成的.事务响应时间是直接衡量系统性能的参数. 4.并发用户数 并发一般分为2种情况。一种是严格意义上的并发，即所有的用户在同一时刻做同一 件事情或者操作，这种操作一般指做同一类型的业务。比如在信用卡审批业务中，一 定数目的拥护在同一时刻对已经完成的审批业务进行提交；还有一种特例，即所有用 户进行完全一样的操作，例如在信用卡审批业务中，所有的用户可以一起申请业务，或者修改同一条记录。 另外一种并发是广义范围的并发。这种并发与前一种并发的区别是，尽管多个用 户对系统发出了请求或者进行了操作，但是这些请求或者操作可以是相同的，也可以 是不同的。对整个系统而言，仍然是有很多用户同时对系统进行操作，因此也属于并 发的范畴。 可以看出，后一种并发是包含前一种并发的。而且后一种并发更接近用户的实际 使用情况，因此对于大多数的系统，只有数量很少的用户进行“严格意义上的并发”。对于WEB性能测试而言，这2种并发情况一般都需要进行测试，通常做法是先进行严格意义上的并发测试。严格意义上的用户并发一般发生在使用比较频繁的模块中，尽 管发生的概率不是很大，但是一旦发生性能问题，后果很可能是致命的。严格意义上 的并发测试往往和功能测试关联起来，因为并发功能遇到异常通常都是程序问题，这 种测试也是健壮性和稳定性测试的一部分。
水质检测九项指标简介 人类在生活和生产活动中都离不开水，生活饮用水水质的优劣与人类健康密切相关。随着社会经济发展、科学进步和人民生活水平的提高，人们对生活饮用水的水质要求不断提高，饮用水水质标准也相应地不断发展和完善。由于生活饮用水水质标准的制定与人们的生活习惯、文化、经济条件、科学技术发展水平、水资源及其水质现状等多种因素有关，不仅各国之间，而且同一国家的不同地区之间，对饮用水水质的要求都存在着差异。? 在这我介绍日常生活中最基本的九项检测,让大家对水质有着进一步的了解： 1、色度：饮用水的色度如大于15度时多数人即可察觉，大于30度时人感到厌恶。标准中规定饮用水的色度不应超过15度。 2、浑浊度：为水样光学性质的一种表达语，用以表示水的清澈和浑浊的程度，是衡量水质良好程度的最重要指标之一，也是考核水处理设备净化效率和评价水处理技术状态的重要依据。浑浊度的降低就意味着水体中的有机物、细菌、病毒等微生物含量减少，这不仅可提高消毒杀菌效果，又利于降低卤化有机物的生成量。 3、臭和味：水臭的产生主要是有机物的存在，可能是生物活性增加的表现或工业污染所致。公共供水正常臭味的改变可能是原水水质改变或水处理不充分的信号。
4、余氯：余氯是指水经加氯消毒，接触一定时间后，余留在水中的氯量。在水中具有持续的杀菌能力可防止供水管道的自身污染，保证供水水质。 5、化学需氧量：是指化学氧化剂氧化水中有机污染物时所需氧量。化学耗氧量越高，表示水中有机污染物越多。水中有机污染物主要来源于生活污水或工业废水的排放、动植物腐烂分解后流入水体产生的。 6、细菌总数：水中含有的细菌，来源于空气、土壤、污水、垃圾和动植物的尸体，水中细菌的种类是多种多样的，其包括病原菌。 7、总大肠菌群：是一个粪便污染的指标菌，从中检出的情况可以表示水中有否粪便污染及其污染程度。在水的净化过程中，通过消毒处理后，总大肠菌群指数如能达到饮用水标准的要求，说明其他病原体原菌也基本被杀灭。标准是在检测中不超过3个/L。 8、耐热大肠菌群：它比大肠菌群更贴切地反应食品受人和动物粪便污染的程度，也是水体粪便污染的指示菌。 9、大肠埃希氏菌：大肠细菌(E.?coli)为埃希氏菌属(Escherichia)代表菌。一般多不致病，为人和动物肠道中的常居菌，在一定条件下可引起肠道外感染。某些血清型菌株的致病性强，引起腹泻，统称病致病大肠杆菌。肠道杆菌是一群生物学性状相似的G-杆菌，多寄居于人和动物的肠道中。埃希菌属（Escherichia）是其中一类，?包括多种细菌，临床上以大肠埃希菌最为常见。大肠埃希菌（）通称大肠杆菌，是所有哺乳动物大肠中的正常寄生菌，一方面
一、软件性能测试需要监控哪些关键指标？ 软件性能测试的目的主要有以下三点： ·评价系统当前性能，判断系统是否满足预期的性能需求。 ·寻找软件系统可能存在的性能问题，定位性能瓶颈并解决问题。 ·判定软件系统的性能表现，预见系统负载压力承受力，在应用部署之前，评估系统性能。 而对于用户来说，则最关注的是当前系统： ·是否满足上线性能要求？ ·系统极限承载如何？ ·系统稳定性如何？ 因此，针对以上性能测试的目的以及用户的关注点，要达到以上目的并回答用户的关注点，就必须首先执行性能测试并明确需要收集、监控哪些关键指标，通常情况下，性能测试监控指标主要分为：资源指标和系统指标，如下图所示，资源指标与硬件资源消耗直接相关，而系统指标则与用户场景及需求直接相关。 性能测试监控关键指标说明： ·资源指标 CPU使用率：指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85%。 内存利用率：内存利用率=（1-空闲内存/总内存大小）*100%，一般至少有10%可用内存，内存使用率可接受上限为85%。 磁盘I/O: 磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是是读IO操作，一般使用% Disk Time（磁盘用于读写操作所占用的时间百分比）度量磁盘读写性能。 网络带宽：一般使用计数器Bytes Total/sec来度量，Bytes Total/sec表示为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较。 ·系统指标： 并发用户数：某一物理时刻同时向系统提交请求的用户数。 在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求。 平均响应时间：系统处理事务的响应时间的平均值。事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间。对于系统快速响应类页面，一般响应时间为3秒左右。 事务成功率：性能测试中，定义事务用于度量一个或者多个业务流程的性能指标，如用户登录、保存订单、提交订单操作均可定义为事务，如下图所示：
常用指标 1、KDJ随机指标 通过一个特定的周期（常为9日、9周等）内出现过的最高价、最低价及最后一个计算周期的收盘价及这三者之间的比例关系，来计算最后一个计算周期的未成熟随机值RSV，然后根据平滑移动平均线的方法来计算K值、D值与J值，并绘成曲线图来研判股票走势。 1) K线是快速确认线——数值在90以上为超买，数值在10以下为超卖； D线是慢速主干线——数值在80以上为超买，数值在20以下为超卖； J线为方向敏感线，当J值大于100，特别是连续5天以上，股价至少会形成短期头部，反之J值小于0时，特别是连续数天以上，股价至少会形成短期底部。 2) 当K值由较小逐渐大于D值，在图形上显示K线从下方上穿D线，显示目前趋势是向上的，所以在图形上K线向上突破D 线时，即为买进的讯号。 实战时当K，D线在20以下交叉向上，此时的短期买入的信号较为准确；如果K值在50以下，由下往上接连两次上穿D值，形成右底比左底高的“W底”形态时，后市股价可能会有相当的涨幅。
3) 当K值由较大逐渐小于D值，在图形上显示K线从上方下穿D线，显示目前趋势是向下的，所以在图形上K线向下突破D 线时，即为卖出的讯号。 实战时当K，D线在80以上交叉向下，此时的短期卖出的信号较为准确；如果K值在50以上，由上往下接连两次下穿D值，形成右头比左头低的“M头”形态时，后市股价可能会有相当的跌幅。 4) 通过KDJ与股价背离的走势，判断股价顶底也是颇为实用的方法： A) 股价创新高，而KD值没有创新高，为顶背离，应卖出； B) 股价创新低，而KD值没有创新低，为底背离，应买入； C) 股价没有创新高，而KD值创新高，为顶背离，应卖出； D) 股价没有创新低，而KD值创新低，为底背离，应买入； 需要注意的是KDJ顶底背离判定的方法，只能和前一波高低点时KD值相比，不能跳过去相比较。 2、MACD移动平均线 利用短期（常用为12日）移动平均线与长期（常用为26日）移动平均线之间的聚合与分离状况，对买进、卖出时机作出研判的技术指标。 1.当DIF和DEA处于0轴以上时，属于多头市场，DIF线自下而上穿越DEA线时是买入信号。DIF线自上而下穿越DEA线时，如果两线值还处于0轴以上运行，仅仅只能视为一次短暂的回落，
?每台服务器每秒平均PV量= （（80%*总PV）/（24*60*60*（9/24）））/服务器数量， ?即每台服务器每秒平均PV量=2.14*（总PV）/* （24*60*60） /服务器数量 ?最高峰的pv量是1.29倍的平均pv值 性能测试策略 1.模拟生产线真实的硬件环境。 2.服务器置于同一机房，最大限度避免网络问题。 3.以PV为切入点，通过模型将其转换成性能测试可量化的TPS。 4.性能测试数据分为基础数据和业务数据两部分，索引和SQL都会被测试到。 5.日志等级设置成warn，避免大量打印log对性能测试结果的影响。 6.屏蔽ESI缓存，模拟最坏的情况。 7.先单场景，后混合场景，确保每个性能瓶颈都得到调优。 8.拆分问题，隔离分析，定位性能瓶颈。 9.根据性能测试通过标准，来判断被测性能点通过与否。 10.针对当前无法解决的性能瓶颈，录入QC域进行跟踪，并请专家进行风险评估。 性能测试压力变化模型
a点：性能期望值 b点：高于期望，系统资源处于临界点 c点：高于期望，拐点 d点：超过负载，系统崩溃 性能测试 a点到b点之间的系统性能，以性能预期目标为前提，对系统不断施加压力，验证系统在资源可接受范围内，是否能达到性能预期。 负载测试 b点的系统性能，对系统不断地增加压力或增加一定压力下的持续时间，直到系统的某项或多项性能指标达到极限，例如某种资源已经达到饱和状态等。 压力测试 b点到d点之间，超过安全负载的情况下，对系统不断施加压力，是通过确定一个系统的瓶颈或不能接收用户请求的性能点，来获得系统能提供的最大服务级别的测试。
稳定性测试 a点到b点之间，被测试系统在特定硬件、软件、网络环境条件下，给系统加载一定业务压力，使系统运行一段较长时间，以此检测系统是否稳定，一般稳定性测试时间为n*12小时。 监控指标 性能测试通常需要监控的指标包括： 1.服务器 Linux（包括CPU、Memory、Load、I/O）。 2.数据库：1.Mysql 2.Oracle（缓存命中、索引、单条SQL性能、数据库线程数、数据池连接数）。 3.中间件：1.Jboss 2. Apache（包括线程数、连接数、日志）。 4.网络：吞吐量、吞吐率。 5.应用： jvm内存、日志、Full GC频率。 6.监控工具（LoadRunner）：用户执行情况、场景状态、事务响应时间、TPS等。 7.测试机资源：CPU、Memory、网络、磁盘空间。 监控工具 性能测试通常采用下列工具进行监控： 1.Profiler。一个记录log的类，阿里巴巴集团自主开发，嵌入到应用代码中使用。 2.Jstat。监控java 进程GC情况，判断GC是否正常。 3.JConsole。监控java内存、java CPU使用率、线程执行情况等，需要在JVM参数中进行配置。 4.JMap。监控java程序是否有内存泄漏，需要配合eclipse插件或者MemoryAnalyzer 来使用。 5.JProfiler。全面监控每个节点的CPU使用率、内存使用率、响应时间累计值、线程执行情况等，需要在JVM参数中进行配置。 6.Nmon。全面监控linux系统资源使用情况，包括CPU、内存、I/O等，可独立于应用监控。
Wｅb性能测试得部分概况一般来说,一个Web请求得处理包括以下步骤: (1)客户发送请求 (2)ｗeb server接受到请求,进行处理; (3)wｅb ｓeｒver向DB获取数据; (4)web ｓerver生成用户得object(页面),返回给用户。给客户发送请求开始到最后一个字节得时间称为响应时间(第三步不包括在每次请求处理中)。 １。事务(Tｒanｓaｃtｉon) 在web性能测试中,一个事务表示一个“从用户发送请求->wｅｂ servｅr接受到请求,进行处理-＞ webｓeｒvｅr向DB获取数据—>生成用户得oｂject(页面),返回给用户”得过程,一般得响应时间都就是针对事务而言得。 2。请求响应时间 请求响应时间指得就是从客户端发起得一个请求开始,到客户端接收到从服务器端返回得响应结束,这个过程所耗费得时间,在某些工具中,响应通常会称为“TTLB”,即＂tiｍe to last bytｅ＂,意思就是从发起一个请求开始,到客户端接收到最后一个字节得响应所耗费得时间,响应时间得单位一般为“秒”或者“毫秒"。一个公式可以表示:响应时间=网络响应时间＋应用程序响应时间。标准可参考国外得３／5/10原则: (1)在3秒钟之内,页面给予用户响应并有所显示,可认为就是“很不错得"; (2)在3～５秒钟内,页面给予用户响应并有所显示,可认为就是“好得”; (３)在５~10秒钟内,页面给予用户响应并有所显示,可认为就是“勉强接受得"; (4)超过10秒就让人有点不耐烦了,用户很可能不会继续等待下去; 3、事务响应时间 事务可能由一系列请求组成,事务得响应时间主要就是针对用户而言,属于宏观上得概念,就是为了向用户说明业务响应时间而提出得、例如:跨行取款事务得响应时间就就是由一系列得请求组成得。事务响应时间就是直接衡量系统性能得参数。 ４、并发用户数 并发一般分为２种情况。一种就是严格意义上得并发,即所有得用户在同一时刻做同一件事情或者操作,这种操作一般指做同一类型得业务、比如在信用卡审批业务中,一定数目得拥护在同一时刻对已经完成得审批业务进行提交;还有一种特例,即所有用户进行完
资料分析常用指标及计算公式 （2） 了解 GDP 随着经济日渐成为人们生活的焦点， 经济领域的一个重要指标 ----------------- GDP （国内生产总 值）越来越受到社会的关注。尽管大多数人都听说过 GDP ，但真正能明白的人恐怕并不多。 日前有报道说我国的 GDP 中有约 10％— 20％是无效成本， 这具体是怎么回事呢？记者采访 了国家统计局国民经济核算司司长许宪春博士。 内在含义是什么 许宪春介绍说， GDP 是宏观经济中最受关注的经济统计数字，因为它被认为是衡量国 民经济发展情况最重要的一个指标。 GDP 是按市场价格计算的国内生产总值的简称，是指 一个国家（或地区） 所有常住单位在一定时期内生产活动的最终成果。 它涉及的是经济活动， 是实实在在的。一般来说，国内生产总值有三种形态，即价值形态、收入形态和产品形态。 从价值形态看， 它是所有常驻单位在一定时期内生产的全部货物和服务价值与同期投入的全 部非固定资产货物和服务价值的差额， 即所有常驻单位的增加值之和； 从收入形态看， 它是 所有常驻单位在一定时期内直接创造的收入之和； 从产品形态看， 它是货物和服务最终使用 减去货物和服务进口。 不应混淆概念 针对日前有关报道说， 我国市场交易中的无效成本占 GDP 的比重至少为 10％— 20％的 问题，许司长说，国家统计局作为 GDP 发布的权威机构至今从未公布过这一数据，无效成 本是经济学名词， 国家统计局在统计 GDP 时从未使用过这个术语。 漏和重复在所难免，但使用无效成本来衡量是不恰当的，至少有关 都不涉及无效成本 的概念。 有关报道中还提到，我国每年因为逃废债务造成的直接损失约 局统计，由于合 同欺诈造成的直接损失约 55 亿元，还有产品质量低劣和制假售假造成的各 种损失至少有 2000 亿元， 由于三角债和现款交易增加的财务费用约为 2000 亿元， 由于不合 理的税外收费和不必要的审批造成的各种费用约 3000 亿元，另外还有逃骗税款损失以及发 现的腐败损失等， 正是这些因素造成无效成本占了国内生产总值的比重至少为 10％— 20％。 对此，许宪春说，上述报道中提到的概念很混乱，它们和 GDP 不是一个口径，比如三 角债、逃废债务造成的损失、欺诈造成的损失等，这些概念和 GDP 都不是同一类概念。通 常我们在计算 GDP 时使用的数据是来自统计部门、财政部门和各有关部门，如金融保险系 统、铁路系统、 民航系统、 邮电系统等， 这些部门的数据均不会讨论无效成本的概念。 当然， GDP 也不是万能的，并非什么数值都能往 GDP 上靠，否则容易造成混乱。 GDP 值是如何确定的 国家统计局每年公布 GDP 数据是怎么得到的呢？许宪春说， GDP 计算需要经过以下几 个过程： 初步估计过程、 初步核实过程和最终核实过程。 初步估计过程一般在每年年终和次 年年初进行。它得到的年度 GDP 数据只是一个初步数，这个数据有待于获得较充分的资料 后进行核实。初步核实过程一般在次年的第二季度进行。初步核实所获得的 GDP 数据更准 确些，但因仍缺少 GDP 核算所需要的许多重要资料，因此相应的数据尚需要进一步核实。 最终核实过程一般在次年的第四季度进行。这时， GDP 核算所需要的和所能搜集到的各种 统计资料、会计决算资料和行政管理资料基本齐备。与前一个步骤相比，它运用了更全面、 更细致的资料，所以这个 GDP 数据显得就更准确些。 虽然在核算 GDP 时， 疏 GDP 三种形态的计算中 1800 亿元；国家工商总
水质中各检测指标的关系 一、水质检测中各指标的定义： 1.悬浮物：水中的悬浮物质是颗粒直径在10-4mm以上的微粒，肉眼可见。 2.浑浊度：由于水中含有悬浮及胶体状态的微粒，使得原是无色透明的水产生浑浊现象，使浑浊的程度称为浑浊度。1L水中含有1mgSiO2所构成的浊度为一个标准浊度单位，简称1度。浑浊度就是指浊度。 3.总硬：水中金属离子的总含量称为水的硬度。（碳酸盐硬度和非碳酸盐硬度之和称为总硬） 4.碱度：是指水中CO32-、HCO3 -、OH-及其他一些弱酸盐类的总和。 5.总铁：铁在水中有几种不同的存在形式，比如二价的亚铁(Fe2+)，三价铁(Fe3+)，铁的配合物(如铁与EDTA形成的配合物)，铁的氧化物(如铁锈)。以上水中各种形态的铁称为总铁。 6.总磷：总磷包括水中溶解物质的含磷和悬浮物中的含磷。 7.电导率：电导率是物质传送电流的能力，是电阻率的倒数。单位电导率（C）简单的说是所测电导率（G）与电导池常数(L/A)的乘积.这里的L为两块极板之间的液柱长度，A为极板的面积。一般通过对溶液电导的测量可掌握水中所溶解的总无机盐类的浓度指标。 8.CL- :水中游离态氯离子的总和。水中氯离子降低方法：沉淀法、离子交换法、电渗析、膜过滤等。
9.PH值： 二、水质中各种指标之间的关系 1.悬浮物与浑浊度的关系：悬浮物主要由泥沙、原生动物、澡类、细菌、病毒以及高分子有机物等组成，常常悬浮水流之中，产生水的浑浊度。浑浊度与悬浮物的质量浓度大小有相关关系，因为颗粒的大小、形状、折射指数也影响悬浮体的光学性质。 值与总碱之间的关系： 总碱度M=[HCO3 - ]+2[CO32-]+[OH-]-[H+] PH≤时，水中只有HCO3 - ≤PH＜时，水中只有CO32-、HCO3 - PH=时，水中只有CO32- ＜PH＜时，水中只有CO32-、OH- PH≥时，水中只有OH- 3.电导率与总硬的关系：水溶液的电导率直接和溶解固体量浓度成正比，而且固体量浓度越高，电导率越大。电导率和溶解固体量浓度的关系近似表示为：μS/cm=1ppm或2μS/cm=1ppm（每百万单位CaCO3）。利用电导率仪或总固体溶解量计可以间接得到水的总硬度值，如前述，为了近似换算方便，1μs/cm电导率= 硬度。但是需要注意：（1）以电导率间接测算水的硬度，其理论误差约20-30ppm
一、性能测试时需关注的指标 [size=4] Memory: 内存使用情况可能是系统性能中最重要的因素。如果系统“页交换”频繁，说明内存不足。“页交换”是使用称为“页面”的单位，将固定大小的代码和数据块从 RAM 移动到磁盘的过程，其目的是为了释放内存空间。尽管某些页交换使 Windows 2000 能够使用比实际更多的内存，也是可以接受的，但频繁的页交换将降低系统性能。减少页交换将显著提高系统响应速度。要监视内存不足的状况，请从以下的对象计数器开始： Available Mbytes:可用物理内存数. 如果Available Mbytes的值很小（4 MB 或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。page/sec: 表明由于硬件页面错误而从磁盘取出的页面数，或由于页面错误而写入磁盘以释放工作集空间的页面数。一般如果pages/sec持续高于几百，那么您应该进一步研究页交换活动。有可能需要增加内存，以减少换页的需求（你可以把这个数字乘以4k就得到由此引起的硬盘数据流量）。Pages/sec 的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致。 page read/sec:页的硬故障，page/sec的子集，为了解析对内存的引用，必须读取页文件的次数。阈值为>5. 越低越好。大数值表示磁盘读而不是缓存读。由于过多的页交换要使用大量的硬盘空间，因此有可能将导致将页交换内存不足与导致页交换的磁盘瓶径混淆。因此，在研究内存不足不太明显的页交换的原因时，您必须跟踪如下的磁盘使用情况计数器和内存计数器： 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的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。 要确定过多的页交换对磁盘活动的影响，请将 Physical Disk\ Avg.Disk sec/Transfer 和 Memory\ Pages/sec 计数器的值增大数倍。如果这些计数器的计数结果超过了 0.1，那么页交换将花费百分之十以上的磁盘访问时间。如果长时间发生这种情况，那么您可能需要更多的内存。Page Faults/sec:每秒软性页面失效的数目（包括有些可以直接在内存中满足而有些需要从硬盘读取）较page/sec只表明数据不能在内存的指定工作集中立即使用。 Cache Bytes：文件系统缓存（File System Cache），默认情况下为50%的可用物理内存。如IIS5.0 运行内存不够时，它会自动整理缓存。需要关注该计数器的趋势变化 如果您怀疑有内存泄露，请监视 Memory\ Available Bytes 和 Memory\ Committed Bytes，以观察内存行为，并监视您认为可能在泄露内存的进程的 Process\Private Bytes、Process\Working Set 和Process\Handle Count。如果您怀疑是内核模式进程导致了泄露，则还应该监视 Memory\Pool Nonpaged Bytes、
网站的性能测试指标包括了Web应用服务器、数据库服务器及系统服务器等各种性能测试。每一项测试中都需要根据项目要求完成测试，本文重点讲述了网站性能测试指标，并加以案例分析。 通用指标（指Web应用服务器、数据库服务器必需测试项) Web服务器指标 数据库服务器性能指标 系统的瓶颈定义
稳定系统的资源状态 通俗理解： ·日访问量 ·常用页面最大并发数 ·同时在线人数 ·访问相应时间 案例： 最近公司一个项目，是个门户网站，需要做性能测试，根据项目特点定出了主要测试项和测试方案： 一种是测试几个常用页面能接受的最大并发数(用户名参数化，设置集合点策略) 一种是测试服务器长时间压力下，用户能否正常操作(用户名参数化，迭代运行脚本) 一种则需要测试服务器能否接受10万用户同时在线操作，如果是用IIS做应用服务器的话，单台可承受的最大并发数不可能达到10万级，那就必须要使用集群，
通过多台机器做负载均衡来实现；如果是用websphere之类的应用服务器的话，单 台可承受的最大并发数可以达到10万级，但为性能考虑还是必须要使用集群，通 过多台机器做负载均衡来实现；通常有1个简单的计算方式，1个连接产生1个session，每个session在服务器上有个内存空间大小的设置，在NT上是3M，那么10万并发就需要300G内存，当然实际使用中考虑其他程序也占用内存，所以准备 的内存数量要求比这个还要多一些。还有10万个用户同时在线，跟10万个并发数是完全不同的2个概念。这个楼上已经说了。但如何做这个转换将10万个同时在 线用户转换成多少个并发数呢？这就必须要有大量的历史日志信息来支撑了。系统日志需要有同时在线用户数量的日志信息，还需要有用户操作次数的日志信息，这 2个数据的比例就是你同时在线用户转换到并发数的比例。另外根据经验统计，对 于1个JAVA开发的WEB系统（别的我没统计过，给不出数据），一般1台双CPU、2G内存的服务器上可支持的最大并发数不超过500个（这个状态下大部分 操作都是超时报错而且服务器很容易宕机，其实没什么实际意义），可正常使用（单步非大数据量操作等待时间不超过20秒）的最大并发数不超过300个。假设 你的10万同时在线用户转换的并发数是9000个，那么你最少需要这样的机器18台，建议不少于30台。当然，你要是买个大型服务器，里面装有200个CPU、 256G的内存，千兆光纤带宽，就算是10万个并发用户，那速度，也绝对是嗖嗖的。 另外暴寒1下，光设置全部进入运行状态就需要接近6个小时。具体的可以拿1个 系统来压一下看看，可能会出现以下情况： 1、服务器宕机； 2、客户端宕机； 3、从某个时间开始服务器拒绝请求，客户端上显示的全是错误； 4、勉强测试完成，但网络堵塞或测试结果显示时间非常长。假设客户端和服务器 之间百兆带宽，百兆/10000=10K，那每个用户只能得到10K，这个速度接近1个 64K的MODEM上网的速度；另外以上分析全都没考虑系统的后台，比如数据库、中间件等。 1、服务器方面：上面说的那样的PC SERVER需要50台； 2、网络方面：按每个用户50K，那至少5根百兆带宽独享，估计仅仅网络延迟就 大概是秒一级的； 3、如果有数据库，至少是ORACLE，最好是SYSBASE，SQL SERVER是肯定顶 不住的。数据库服务器至少需要10台4CPU、16G内存的机器； 4、如果有CORBA，那至少再准备10台4CPU、16G内存的机器；再加上负载均衡、防火墙、路由器和各种软件等，总之没个1000万的资金投入，肯定搞不定。
常用指标说明 反趋向指标 KDJ ROC W&R威廉指标 RSI BIAS ADTM ATR OSC UDL KDJ 指标说明：KDJ，其综合动量观念、强弱指标及移动平均线的优点，早年应用在期货投资方面，功能颇为显著，目前为股市中最常被使用的指标之一。 买卖原则： 1 K线由右边向下交叉D值做卖，K线由右边向上交叉D值做买。 2 高档连续二次向下交叉确认跌势，低挡连续二次向上交叉 确认涨势。 3 D值<20%超卖，D值>80%超买，J>100%超买，J<10%超卖。 4 KD值于50%左右徘徊或交叉时，无意义。
5 投机性太强的个股不适用。 6 可观察KD值同股价的背离，以确认高低点。 ROC 当ROC向下跌破零，卖出信号；ROC向上突破零，买入信号。股价创新高，ROC未配合上升，显示上涨动力减弱。股价创新低，ROC未配合下降，显示下跌动力减弱。股价与ROC从低位同时上升，短期反弹有望。股价与ROC从高位同时下降，警惕回落。 W&R威廉指标 算法： N日内最低价与当日收盘价的差，除以N日内最高价与最低价的差，结果放大100倍 参数： N 统计天数一般取14天 用法： 1.低于20，超买，即将见顶，应及时卖出 2.高于80，超卖，即将见底，应伺机买进 3.与RSI、MTM指标配合使用，效果更好 RSI RSIS为1978年美国作者Wells WidlerJR。所提出的交易方法之一。所谓RSI英文全名为Relative Strenth Index，中文名称为相对强弱指标．RSI的基本原理是在一个正常的股市中，多空买卖双方的力道必须得到均衡，股价才能稳定;而RSI是对于固定期间内，股价上涨总幅度平均值占总幅度平均值的比例。 1 .RSI值于0-100之间呈常态分配，当6日RSI值为80‰以上时，股市呈超买现象，若出现M头为卖出时机;当6日RSI 值在20‰以下时，股市呈超卖现象，若出现W头为买进时机。
通用指标（指Web应用服务器、数据库服务器必需测试项) Web服务器指标
数据库服务器性能指标 系统的瓶颈定义
稳定系统的资源状态 通俗理解： 日访问量 常用页面最大并发数
同时在线人数 访问相应时间 案例： 最近公司一个项目，是个门户网站，需要做性能测试，根据项目特点定出了主要测试项和测试方案： 一种是测试几个常用页面能接受的最大并发数(用户名参数化，设置集合点策略) 一种是测试服务器长时间压力下，用户能否正常操作(用户名参数化，迭代运行脚本) 一种则需要测试服务器能否接受10万用户同时在线操作，如果是用IIS做应用服务器的话，单台可承受的最大并发数不可能达到10万级，那就必须要使用集群，通过多台机器做负载均衡来实现；如果是用websphere之类的应用服务器的话，单台可承受的最大并发数可以达到10万级，但为性能考虑还是必须要使用集群，通过多台机器做负载均衡来实现；通常有1个简单的计算方式，1个连接产生1个session，每个session在服务器上有个内存空间大小的设置，在NT上是3M，那么10万并发就需要300G内存，当然实际使用中考虑其他程序也占用内存，所以准备的内存数量要求比这个还要多一些。还有10万个用户同时在线，跟10万个并发数是完全不同的2
个概念。这个楼上已经说了。但如何做这个转换将10万个同时在线用户转换成多少个并发数呢？这就必须要有大量的历史日志信息来 支撑了。系统日志需要有同时在线用户数量的日志信息，还需要有用户操作次数的日志信息，这2个数据的比例就是你同时在线用户转换到并发数的比例。另外根据经验统计，对于1个JAVA开发的WEB 系统（别的我没统计过，给不出数据），一般1台双CPU、2G内存的服务器上可支持的最大并发数不超过500个（这个状态下大部分操作都是超时报错而且服务器很容易宕机，其实没什么实际意义），可正常使用（单步非大数据量操作等待时间不超过20秒）的最大并发数不超过300个。假设你的10万同时在线用户转换的并发数是9000个，那么你最少需要这样的机器18台，建议不少于30台。当然，你要是买个大型服务器，里面装有200个CPU、256G的内存，千兆光纤带宽，就算是10万个并发用户，那速度，也绝对是嗖嗖的。 另外暴寒1下，光设置全部进入运行状态就需要接近6个小时。具体的可以拿1个系统来压一下看看，可能会出现以下情况： 1、服务器宕机； 2、客户端宕机； 3、从某个时间开始服务器拒绝请求，客户端上显示的全是错误； 4、勉强测试完成，但网络堵塞或测试结果显示时间非常长。假设客户端和服务器之间百兆带宽，百兆/10000=10K，那每个用户只
常用指标详解 一：WR威廉指标 一．用途： 该指标表示的涵义是当天的收盘价在过去一段日子的全部价格围所处的相对位置，是一种兼具超买超卖和强弱分界的指标。它主要的作用在于辅助其他指标确认讯号。 二．使用方法： 1、从WR的绝对取值方面考虑。 A、当WR 高于80，即处于超卖状态，行情即将见底，应当考虑买进。 B、当WR 低于20，即处于超买状态，行情即将见顶，应当考虑卖出。 2、从WR的曲线形状考虑。 A、在WR进入高位后，一般要回头，如果这时股价还继续上升，这就产生背离，是卖出的信号。 B、在WR进入低位后，一盘要反弹，如果这时股价还继续下降，这就产生背离，是买进的信号。 C、WR连续几次撞顶（底），局部形成双重或多重顶（底），则是卖出（买进）的信号。 三．使用心得： 1．W%R主要可以辅助RSI，确认强转弱或弱转强是否可靠？RSI向上穿越50阴阳分界时，回头看一看W%R 是否也同样向上空越50？如果同步则可靠，如果不同步则应多参考其他指标讯号再作决定。相反的，向下穿越50时，也是同样的道理。注意！比较两者是否同步时，其设定的参数必须是相对的比例，大致上W%R 5日、10日、20日对应RSI6日、12日、24日，但是读者可能可以依照自己的测试结果，自行调整其最佳对应比例。 2．W%R进入超买或超卖区时，应立即寻求MACD讯号的支援。当W%R进入超买区时，我们当成一种预警效果，回头看看MACD是否产生DIF向下交叉MACD的卖出讯号？一律以MACD 的讯号为下手卖出的时机。相反的，W%R进入超卖区时，也适用同样的道理。 四．计算公式： n日WMS=[(Hn-Ct)/(Hn-Ln)] ×100 式中：Cn---当天的收盘价； Hn和Ln---最近N日（包括当天）出现的最高价和最低价 二：布林线BOLL 一．用途： 该指标利用波带显示其安全的高低价位。股价游走在"上限"和"下限"的带状区间，当股价涨跌幅度加大时，带状区会变宽，涨跌幅度缩小时，带状区会变窄。 二．使用方法： 1．向上穿越"上限"时，将形成短期回档，为短线的卖出时机。 2．股价向下穿越"下限"时，将形成短期反弹，为短线的买进时机。 3．当布林线的带状区呈水平方向移动时，可以视为处于"常态围"，此时，采用1、2两个使用方法，可靠
水中总氮的测定（过硫酸钾氧化紫外分光光度法） （一）主要试剂： 碱性过硫酸钾溶液：称取4g过硫酸钾(K2S208)和1.5g氢氧化钠，溶于无氨水中，稀释至100mL。 1mol/L的HCL ：取8.33 mL的浓盐酸稀释至100 mL。 （二）测定步骤： 水样加5mL碱性过硫酸钾溶液，包扎高温消解30min。于消解完全的试样中加入1mL 1mol/L的HCL，加水至刻度，充分混匀后，分别于220nm和275nm波长处测定吸光值，吸光度计算：A=A220nm-2A275nm。 水中总磷的测定（过硫酸钾氧化-钼锑抗比色法） （一）主要试剂： 6.5mol/L钼锑储备液：取180.6ml分析纯浓硫酸，缓缓加入到400ml蒸馏水中，不断搅拌，冷却。加入20g钼酸铵和0.5g酒石酸锑钾，搅拌，待溶液冷却后定容至1000ml。 钼锑抗混合显色剂：取100ml钼锑贮存液，加入1.5g抗坏血酸，此试剂宜现配现用。 5%的过硫酸钾溶液：5g过硫酸钾溶解于水，定容至100ml。 二硝基酚指示剂：称取0.2克2,6-二硝基酚溶于100ml水中。 （二）测定步骤： 水样加4ml 5%的过硫酸钾溶液，包扎高温消解30min。 测定：经消解后的样品加入2,6-二硝基酚指示剂2滴，用氢氧化钠和盐酸调节至微黄色。再加入2.5 ml 6.5mol/L钼锑抗显色剂，定容摇匀，放置30min后，在700nm波长处测量吸光度。 水中氨氮的测定（苯酚-次氯酸钠分光光度法） （一）主要试剂： 1%EDTA溶液：溶解1g EDTA于100ml水中，用浓氢氧化钠将pH调至10。 溶液B：溶解5g苯酚和25mg亚硝酰氰化钠（亚硝酰铁氰化钠）于水中稀释至500毫升，放棕色瓶中，置于冰箱中贮存。 溶液C：溶解2.5g氢氧化钠，18.7 g磷酸氢二钠和15.9g磷酸三钠于水中，加入含有效氯4.3ml次氯酸钠，定溶至500ml，放棕色瓶中，置于冰箱中贮存。 （二）测定步骤： 于抽滤过后的水样中加1ml 1%EDTA，加入5ml B溶液，5ml C溶液，摇匀，定容，置37℃恒温水浴中发色30分钟。在625nm处测定吸光度。 水中硝态氮的测定（紫外分光光度法） 测定方法：于抽滤后的试样中加入1mL 1mol/L的HCL，加水至刻度，充分混匀后，分别于220nm和275nm波长处测定吸光值，吸光度计算：A=A220nm-2A275nm。 水质高锰酸盐指数的测定 （一）试剂配制： 0.1mol/L KMnO4储备液：3.2g高锰酸钾溶解定容至1L。 0.1mol/L的草酸钠储备液: 称取0.6705g经120℃烘干2h并放冷的草酸钠溶解并定
Weｂ性能测试的部分概况一般来说,一个Ｗeb请求的处理包括以下步骤: (1)客户发送请求 (2)weｂservｅr 接受到请求,进行处理; (3)weｂ servｅｒ向ＤB获取数据; (４)web serｖｅr生成用户的obｊeｃt(页面),返回给用户。给客户发送请求开始到最后一个字节的时间称为响应时间(第三步不包括在每次请求处理中)。 1.事务(Tranｓacｔion) 在ｗeb性能测试中,一个事务表示一个“从用户发送请求->web sｅrveｒ接受到请求,进行处理-＞ｗeｂ serveｒ向DＢ获取数据->生成用户的object(页面),返回给用户”的过程,一般的响应时间都就是针对事务而言的。 2、请求响应时间 请求响应时间指的就是从客户端发起的一个请求开始,到客户端接收到从服务器端返回的响应结束,这个过程所耗费的时间,在某些工具中,响应通常会称为“TTLB”,即＂tｉme ｔｏ lａst ｂｙｔe",意思就是从发起一个请求开始,到客户端接收到最后一个字节的响应所耗费的时间,响应时间的单位一般为“秒”或者“毫秒”。一个公式可以表示:响应时间＝网络响应时间+应用程序响应时间。标准可参考国外的3/５/1０原则: (1)在3秒钟之内,页面给予用户响应并有所显示,可认为就是“很不错的”; (2)在３~５秒钟内,页面给予用户响应并有所显示,可认为就是“好的”;
(３)在5～10秒钟内,页面给予用户响应并有所显示,可认为就是“勉强接受的”; (４)超过１0秒就让人有点不耐烦了,用户很可能不会继续等待下去; 3、事务响应时间 事务可能由一系列请求组成,事务的响应时间主要就是针对用户而言,属于宏观上的概念,就是为了向用户说明业务响应时间而提出的、例如:跨行取款事务的响应时间就就是由一系列的请求组成的、事务响应时间就是直接衡量系统性能的参数、 ４.并发用户数 并发一般分为2种情况。一种就是严格意义上的并发,即所有的用户在同一时刻做同一件事情或者操作,这种操作一般指做同一类型的业务。比如在信用卡审批业务中,一定数目的拥护在同一时刻对已经完成的审批业务进行提交;还有一种特例,即所有用户进行完全一样的操作,例如在信用卡审批业务中,所有的用户可以一起申请业务,或者修改同一条记录。 另外一种并发就是广义范围的并发。这种并发与前一种并发的区别就是,尽管多个用户对系统发出了请求或者进行了操作,但就是这些请求或者操作可以就是相同的,也可以就是不同的。对整个系统而言,仍然就是有很多用户同时对系统进行操作,因此也属于并发的范畴。 可以瞧出,后一种并发就是包含前一种并发的。而且后一种并发更接近用户的实际使用情况,因此对于大多数的系统,只有数量很少的用户进行“严格意义上的并发”。对于ＷEB性能测试而言,这2种并发情况一般都需要进行测试,通常做法就是先进行严格意义上的并发测试。严格意义上的用户并发一般发生在使用比较频繁的模块中,尽管发生的概率不就是很大,但就是一旦发生性能问题,后果很可能就是致命的。严格意义上的并发测试往往与功能测试关联起来,因为并发功能遇到异常通常都就是程序问题,这种测试也就是健壮性与稳定性测试的一部分。