《淘宝性能测试白皮书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的完成需要来回传输几个页面才可以完成。