引言：

　　线上PV是性能测试同学以及架构、开发、运营同学非常关注的参数；

　　PV在性能测试中的表现形式是以TPS来体现的，两者有一个转换公式，如下：

　　TPS平均值 =( (PV*80%)/(24*60*60*40%))/服务器数量 =  pv/s

　　TPS峰值 = (((PV*80%)/(24*60*60*40%))*1.6) /服务器数量=  pv/s

　　前提条件：

　　保证性能测试在一个干净、稳定、独立、无毒、真实的性能测试环境下执行。

　　Note： 性能测试应该尽量真实模拟生产线上的软硬件环境、应用服务参数配置、在线user访问、业务逻辑等。

　　最近性能测试项目，TPS不稳定的表现形式：

　　1. TPS图表呈瀑布型

　　2. TPS整体逐步下降且有波动

　　3. 部分transaction较有规律的波动

　　4. TPS图呈矩形的

　　5. 某一时间段内有较大波动的

　　6. 批量参数请求处理模式

　　7. Transaction ‘短暂消失’且下降明显

　　9. TPS平稳运行一段时间后骤降

　　8. 正常的RPS图

　　分析原因：

　　引起TPS不正常的原因至少有以下几种情况：

　　i. 代码(需要优化,这类在性能测试中占多数）

　　ii.网络原因

　　iii.服务器遇到大批量请求，有延迟处理的迹象

　　iv.压力高峰时server端短暂休克（页面显示不全，或者不显示需要多次刷新）

　　v.服务器运行不稳定

　　vi.应用服务运行过程中受到其它非性能测试service干扰

　　感想：

　　需要调优并且重新执行性能场景：

　　处理方式：

　　1. 调优了，有所提高；

　　2. 没有调优，结果稳定了些。

　　有时候，TPS会有波动，我们是否也应该有个允许的波动范围；因为对某些大型数据量交换场景（搜索类场景），TPS轨迹不能总是一条直线。尤其对以下几种情况：

• 搜索
• 查询
• 调用接口
• Peak Load时

　　但是从一方面来讲，如果没有允许波动范围，只是用我们的猜测去下结论，很可能会导致我们的性能测试功亏一篑，遗漏掉一些本该发现的性能bug，或者发现不了一些潜在的性能瓶颈点。

　　建议：

　　如果我们制定一个合理的TPS波动范围标准，我们可以有效的去实施，有理有据，这样就避免了跟设计、开发人员的沟通成本。

　　制定一个标准是给我们的性能测试工作作为参考，标准是人为制定的，当然可以灵活运用，具体问题做具体分析。