什么是性能问题

性能问题表现第一种

小规模使用的时候性能表现很好，在大规模使用的时候，性能变得很差，业务响应时间随业务压力变得越来越慢

原因：代码中对资源使用产生的瓶颈，后续的请求在资源(cpu、内存、锁、线程池)上排队

例子： 没有索引的表的查询 随着业务量增加，表的行数快速增加，查询越来越慢

性能测试解决的大部分问题是这种类型

性能问题表现第二种

在一定压力情况下，应用的性能突然变差或者不可使用

原因：应用突然进入了一个异常逻辑，占用了很多资源，并且无法从异常状态下退出

例子：fetion 后台 初期版本中使用同步的socket连接，网络单点异常的时候，全网的服务都不可用。

性能测试很难解决这种类型的性能问题。很难定位异常逻辑是什么。

性能问题表现第三种

在压力大于某个阀值的情况下，总会出现少量业务错误

原因：业务逻辑考虑不严密，导致少量流程不是按照期望发生

例子：取一个值做uniquekey值，锁保护不够导致，取值不唯一。

性能测试能够很好的解决这类问题。

一些基本概念详细解析

响应时间

Response time是性能测试中考察被测试软件性能的一个指标；

Response time包括从客户端请求发出开始，到reponse 应答回来后的时间总和，可能包括：

网络传输

cpu上可执行队列的等待时间

cpu计算

线程执行sleep语句的时间

锁、闩的等待时间

磁盘io等待时间等。

吞吐量tps

吞吐量 tps是考察性能的另一个指标；

单位时间内完成业务量的多少，tps 是一个具体的常用的指标，每秒钟完成的业务个数。

通常的误会是认为response time一定会影响tps，这个不一定成立

并发

并发是指同时被处理的请求个数，同时处理可以有2个含义

同时都在线程堆栈上的请求

指在正在cpu上处理的请求

这里指得是后者。

那么最大的tps = Concurrency*1000 /请求在cpu上的处理时间(ms)

思考时间

Think Time思考时间 Think time是在测试代码中出现的概念，为了在测试代码中模拟时间用户的思考时间而加的sleep时间，2个作用

第一作用是控制测试代码的业务执行速度，完美地执行出预计的场景

模拟实际用户执行的思考时间

有状态的服务 很重要

无状态的服务 不重要

测试压力 business load

测试压力是什么？或者是客户做了什么导致服务器产生压力

对于无状态服务器，客户端的压力来源于客户端的请求数/秒

对于有状态服务器，客户端的压力是客户端的在服务器的留存信息和rps。

数据库是一个有状态的服务器

有状态的服务器更容易有性能问题

性能测试过程

完美的测试过程

完美的性能测试就是软件在现网上实际运行的过程

实验室状态下永远也无法完全模拟

性能测试无法找到所有的问题

性能测试方案

定义了在影响软件运行性能的各个方面采用什么样的方法和策略模拟真实的情况，达到尽量真实模拟的目的。

非常重要， 决定了测试的成败

基础数据 : 测试之前，测试环境中已有的数据总和

关于基础数据的原则

必须调查或者预测出数据库表中每个表应该有多少行的数据。

而且数据取值要实际情况一样丰富。

数据长度和实际情况相同

基础数据决定着数据库server的cpu、内存、io使用或其他多种资源的使用逻辑。

测试数据： 从基础数据中选取的，参与到性能测试中的数据

选择原则

在应用合理范围内随机挑选数据、挑选足够的量。

挑选数据的方式通常影响数据库的内存和io，有状态服务的cpu和内存，线程、锁等。

业务模型

测试完成哪些业务？完成速率？

建立业务模型的原则

最好是实际用户行为的统计，如果没有借助同类软件的用户行为统计，再没有，根据有经验人员的预估。

把用户所有可能使用业务按使用频繁程度排序，频繁程度越高就越应该纳入测试场景。

查看业务消耗计算资源的程度，预计消耗程度越大的越应该纳入测试场景

建立业务模型的原则

多个业务在一起的复杂场景：把所有业务的在周期内的tps放在一起考察，一般情况下所有业务会有一致性的行为，即tps变化一致，取峰值阶段的tps为测试通过标准。

如何有明显不一致，需要取2到多个典型场景分别测试

测试场景

多大测试压力（多少在线用户或者rps是多少）

预估和实际预测的结果

测试多长时间？

无状态的几个小时

有状态的几天

硬件资源选择的原则

大型分布式软件的中每个角色都需要负载均衡的设计才能够平滑扩展。 那么测试环境只需要取得这样一个环境的小的集合就可以了。

单个硬件设备最好使用上线后用的机器，因为不同设备之间的差异很大，无法但从cpu、内存、tpcc等指标来分析硬件之间的差异。

使用差异很大的设备测试只能定性的说明问题，无法定量

如何编写测试代码

能和实际的客户一样完成业务功能。这是最基本的能力，也是性能测试的基础，必选

对每次与服务器的交互做严格的结果正确性检查，保证功能执行的正确性。性能测试的目标不仅仅是提供测试的工作压力，而且要保证测试功能的正确性，必选。

提供出错日志功能，这对于初步分析性能问题，或者测试代码、被测试软件的功能问题都是非常好的手段，可选

测试代码在设计时要意识地保证数据库的数据量的稳定性，可选。

提高测试代码可配置性，保证在多种不同的测试场景下，测试场景可迅速建立，可选。

测试执行人的能力要求

测试人需要按照测试方案的要求，配置测试代码和使用测试工具建立起方案中的测试场景，必选。

按照方案选择合理的测试数据，必选。

测试人必须完全了解测试代码的每个细节，如果在测试中发现测试任何错误，如果这个错误是测试代码或者场景设置的问题，测试人有能力解决，必选。

判断测试的结果分析是否有性能问题，必选。

对于服务方的问题，提供当时的上下文环境供开发和优化人员分析，可选。

能够解决被测试软件方由于配置错误等引起的简单问题，可选。

软件优化的基本步骤

性能问题有哪些？ cpu的瓶颈、内存的瓶颈、磁盘io的瓶颈、网络io的瓶颈、线程之间同步的瓶颈等等

软件优化好以后应该是什么样？特征

Tps 基本上和cpu使用率正相关

响应时间1-50 ms， tps 几百几千几万

参考测试设备 cpu等资源的情况

业务完成过程的复杂度

如果有性能瓶颈

首先排查其它瓶颈，保证tps和cpu正相关。

察看是否有cpu滥用的现象

“所有高cpu的问题都是不必要的循环引起的”---个人体会

没有索引的表的查询

应用本地没有缓存，反复从数据库或者其它应用获取。

线程数太多，导致过多的上下文切换。

性能测试的限制

性能测试何时测不准？

性能测试有限性导致测不准

没有测试到的场景和业务

软件异常流程

硬件、网络环境不一样

比如客户端特别移动客户端网速慢

用户行为变化导致的测不准

用户数据增长导致的测不准

一个性能优化的例子

被测试系统问题介绍：一个 使用 dot net remoting的系统，在线上使用 1年多，突然出现 严重的outofmemory的问题

负载非常：忙时remoting的调用大约0.35个/秒

Cpu使用率低： 平均只有 1%

内存只升不降，在几天内达到最大值，导致 outofmemory。如下图：

从应用来看，每天只有20个客户端在线使用，几百个tcp连接怎么来的？

原因：网络异常，连接已经中断，但server没有感知。

应用部署在win2000上， win2000 无法感知连接异常

解决办法：升级到win2003， 在注册表增加tcp连接的检测，每90秒检查一次