网站性能测试PV到TPS的转换以及TPS的波动和淘宝性能测试要点

《淘宝性能测试白皮书V0.3》

性能测试的难点不在于测，在于测出的数据和实际的对照关系，以及测试出来的数据对性能的评估（到底是好，还是不好）。

淘宝性能测试白皮书，解决了我的4个问题：1、PV到TPS的转换关系。2、TPS的波动标准。3、压力变化以及测试类型。4、网页测试的标准（可惜很多数据都抹掉了）

1、PV到TPS的转换

日PV对于一个网站，很容易就统计出来，但是LoadRunner性能测试时，只有TPS可供参考。日PV和TPS之间如何对应？公式就是80%的日PV，发生在T小时内。则公式为：

TPS =  日PV * 80% / 24 * 60 * 60 * (T/24)

定义 R = 1万 * 80% / 24 * 60 * 60 * (T/24)  = 10000 * 24 * 0.8 / 24 * 3600 * T = 2.2222/T

TPS = 日PV（万） * R 这里的TPS就是平均的TPS。

可以T的值代入，则求出R的值即可

T      6             8             10            12

R      0.3704    0.2778    0.2222     0.1852

10w     3.704      2.778      2.222       1.852

100w   37.04      27.78      22.22       18.52

1000w 370.4      277.8      222.2       185.2

1亿       3704       2778       2222        1852

关于TPS 我再多说两句，单就静态页面，TPS大概能到1W+，简单数据库操作大概2K+的样子，用Cache大概能到5K+。

峰值的TPS，可以从图中看出来。

2、TPS的波动标准

TPS应该是一个比较平稳的曲线，而不是上下波动

TPS波动范围 = TPS标准差/TPS平均值 * 100%

在5%内算是正常的

3、测试压力变化

pdf中的图1-8
a点：性能期望值
b点：高于期望，系统资源处于临界点
c点：高于期望，拐点
d点：超过负载，系统崩溃

性能测试 
a点到b点之间的系统性能
定义：狭义的性能测试，是指以性能预期目标为前提，对系统不断施加压力，验证系统在资源可接受范围内，是否能达到性能预期。

负载测试
b点的系统性能
定义：狭义的负载测试，是指对系统不断地增加压力或增加一定压力下的持续时间，直到系统的某项或多项性能指标达到极限，例如某种资源已经达到饱和状态等。

压力测试
b点到d点之间
定义：狭义的压力测试，是指超过安全负载的情况下，对系统不断施加压力，是通过确定一个系统的瓶颈或不能接收用户请求的性能点，来获得系统能提供的最大服务级别的测试。

稳定性测试
a点到b点之间
定义：狭义的稳定性测试，是指被测试系统在特定硬件、软件、网络环境条件下，给系统加载一定业务压力，使系统运行一段较长时间，以此检测系统是否稳定，一般稳定性测试时间为n*12小时。

4、网站测试标准

==========================================================================

性能相关的系列文章：

LoadRunner利用ODBC编写MySql脚本 
LoadRunner压力测试时监控服务器Linux的资源情况 
压力测试衡量CPU的三个指标：CPU Utilization、Load Average和Context Switch Rate 
高性能服务器架构(High-Performance Server Architecture) 
网站性能测试PV到TPS的转换以及TPS的波动 
用GTmetrix来优化你的网页（集成了YSlow、FireBug的功能）

Q&A

因为CSDN评论不知道为什么没法用了，所以贴在这里吧

Q：yxt168118 能否请作者将TPS的T，在测试脚本中，怎么定义说明一下？我是将某个关键操作定义为一个事务（T），这样测试出来的TPS很难达到10。

A：回复 yxt168118：定义T transaction 事务，是根据测试目的来决定的，如果是性能测试，T定义为一次请求，如果是可用性测试，T定义为整个页面的加载，主要看响应时间用户是否能接受。TPS高低和操作的复杂程度、以及后台扩展、以及T的定义是相关的。一般，单次的请求，单台机器，百数量级上是正常的。另外，在一次请求中，不要每次都去初始化一些比如用户等数据，如果有很多的数据库操作，TPS也会低一些，如果达不到10，还需要优化，比如看看数据库方面是否有优化的空间，比如索引。

淘宝性能测试要点

摘自：http://www.51testing.com/html/29/n-197229.html

发布时间: 2009-11-30 14:30    作者: 未知    来源: 51Testing软件测试网采编

• 每台服务器每秒平均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等，可独立于应用监控。

　　7.Valgrind。监控C/C++程序是否存在内存泄漏，基于linux环境。

　　8.Vmmap和ApplicationVerifier。监控C/C++程序是否存在内存泄漏，基于windows环境。

　　性能分析

　　可按以下顺序：

　　中间件瓶颈（apache/jboss参数配置、数据库参数配置）->

　　应用服务的debug log ->

　　应用服务的filter log ->

　　本应用的性能瓶颈（SQL语句、索引、业务逻辑、线程池设置、算法）->

　　服务提供者的性能瓶颈 ->

　　相关联的底层存储应用的性能瓶颈

　　分析标准

　　通过性能指标的表现形式，分析性能是否稳定。比如：

　　1.响应时间是否符合性能预期，表现是否稳定。

　　2.应用日志中，超时的概率，是否在可接受的范围之内。

　　3.TPS维持在多大的范围内，是否有波形出现，标准差有多少，是否符合预期。

　　4.服务器CPU、内存、load是否在合理的范围内，等等。

　　分析工具

　　对于部分性能指标，可借助自动分析工具，统计出数据的总体趋势：

　　1.LoadRunner analysis

　　LoadRunner analysis是loadrunner的一个部件，用于将运行过程中所采集到的数据生成报表，主要用于采集TPS、响应时间、服务器资源使用情况等变化趋势。

　　2.Memory Analyzer

　　Memory Analyzer工具可以解析Jmap dump出来的内存信息，查找是否有内存泄漏。

　　3.nmon_analyser

　　nmon工具可以采集服务器的资源信息。列出CPU、MEM、网络、I/O等资源指标的使用情况。

PV->TPS转换模型 
为了使 PV在性能测试环境下可量化，根据 PV的概念，通过以下方式将其转换成 TPS。 
1.  性能测试脚本中，只保留与性能点相关的内容，异步处理的，保留多个请求，从而
确保压力目标。 
2.  在执行场景中，不模拟浏览器缓存，确保每次请求都到达应用服务器，使得
LoadRunner的一个请求等同于一个 PV。 
3.  在执行场景中，每次迭代，都模拟一个新用户，而且清除用户缓存信息，确保每个
用户每次发送请求都是全新的。 
结论：通过以上三步，将 PV转化成性能测试工具可识别的 TPS。换言之，1PV=1TPS。

PV Page View 
PV是 Page View的缩写。用户通过浏览器访问页面，对应用服务器产生的每一次请求，
记为一个 PV。淘宝性能测试环境下，将这个概念做了延伸，系统真实处理的一个请求，视
为一个 PV。即，PV的概念也适用于接口。

不对吧
1PV不等于1TPS
TPS×每个用户的访问量=页面访问率PV

PV->TPS转换模型 
为了使 PV在性能测试环境下可量化，根据 PV的概念，通过以下方式将其转换成 TPS。 
1.  性能测试脚本中，只保留与性能点相关的内容，异步处理的，保留多个请求，从而
确保压力目标。 
2.  在执行场景中，不模拟浏览器缓存，确保每次请求都到达应用服务器，使得
LoadRunner的一个请求等同于一个 PV。 
3.  在执行场景中，每次迭代，都模拟一个新用户，而且清除用户缓存信息，确保每个
用户每次发送请求都是全新的。 
结论：通过以上三步，将 PV转化成性能测试工具可识别的 TPS。换言之，1PV=1TPS。

偶也认为1PV=1TPS不够准确？一个TPS等于几个PV得看你是如何定义TPS的吧？TPS不是每秒处理的事物数么？也许一个TPS的完成需要来回传输几个页面才可以完成。