性能测试整理.docxVIP

性能测试整理 前言 性能测试的核心在于保障产品质量。 一切互联网产品都是不可信任的。 随时更新。 产品可能存在的问题。 实际上并不是所有产品都对性能有很高的要求。 所谓传统玩法和互联网玩法最大的区别在于，传统玩法的一个系统只针对一小个团体，而互联网玩法则是一个系统面向全世界。 传统玩法的软件对系统性能的要求并不高。很多时候只要支撑最多不超过一万人的数据量。因此传统系统的性能测试实际上相当的简单，设计用户场景、根据用户场景对系统做性能测试。借助各种工具可以很方便的帮你模拟各种用户实操场景。在这种性能测试中，唯一需要考虑的就是该系统的性能能否满足客户的使用。 互联网玩法对性能要求则高的多。老板么总是野心勃勃的将全世界的用户都一网打尽。特别是平头哥的马老板。 互联网玩法中通常会采用分布式系统架构设计，并使用服务器集群。这使系统在满足产品经理的需求的同时承担了更大的性能挑战。 高并发：服务器需要承载高并发 高可用：服务器集群节点越多，单个节点出问题的可能性越大，需要确保在单个节点挂掉的情况下请求依然可以正常处理。 可靠性：服务器集群、数据库集群、缓存集群对数据的正确获取、存储、保存的能力。 一致性：数据库集群数据的同步问题，节点的一致性问题。 可拓展性：当业务增长时可通过增加节点的方式增加处理能力。 网络同样也是一个巨大的问题，分布式服务的特点导致不同节点之间调用速度慢、调用不稳定等问题。 在接手能测试任务后，需要根据产品的特性来思考可能会面临的问题。上述的一些问题是互联网分布式架构都存在的问题。根据产品的不同，一些独特的特性或者服务架构可能会产生更古怪的性能问题。此类问题很多时候很难第一时间被识别，需要通过经验积累或者 分析产品架才能尽早发现问题。 一些经验。 多节点数据写入 非常常见的问题，一些逻辑在做多节同时向数据库写数据的过程中，因为性能问题通常不会加锁的限制。业务可能会存在一种逻辑，一个账号产生数据时生成一个独特的id并做储存，后续此账号产生的数据更新在这个id中。这种逻辑可能会面临一个重复写入的问题。 当一个账号在第一次产生数据时同时通过两个不同的节点向数据库写入数据时，两个节点首先会查询数据库，判断是否存在这条数据，此时两个节点均发现数据库里无这个账号的数据。两个节点同时向库中插入数据。此时就出现了数据的错误，同一个账号产生了两条记录。 逐级上报导致的死循环 通常存在于存在组织架构的系统中。例如一个存在信息逐级上报的特性，当组织架构形成一个回环时（A是B上级，B是C上级，C是A上级）因为逐级上报的机制，这个上报过程将永远持续下直到服务毁灭。 这种特性无法通过功能测试发现。如果这个上报过程创建对象后会做销毁，那么这个问题的产生只会固定增加服务器开销。如果创建的对象到所有上报完成后才销毁，那么这个问题只有在内存积累到一定程度后才会拖垮服务，这可能需要一整天甚至数天时间才会被发现。在频繁发版的测试环境很难发现这种问题。 视屏流量未隔离影响其他业务 一些非常消耗网络资源的业务需要做隔离，以免高峰期影响其他业务。视频是最典型的业务，通常使用独立的网络连接。同样语音、im相关功能视情况也要判断是否需要做隔离。产品上线前一定要做确认。 报表生成与下载 大量数据下的报表生成与下载一直是一个难题。 通常报表下载会选择excel或csv格式，csv速度很快但是不支持格式化。因此很多业务依然忍痛选择excel。但excel面临大量的性能问题。 不同版本的excel能容纳的数据量是不同的，插入数据的速度也是不同的。以java代码为例。java生成一个一万数据的excel报表，在优化良好的情况下也需要一分钟以上的时间。且在生成过程中会产生大量对象在内存中。同时报表生成时查库的过程可能会长期占有数据库链接。不管是极高的内存消耗还是高IO，都有可能会影响到同服务的其他业务。 这其中附加了一个体验为，如何让用户对excel文件的生成过程有有感知。客户需要一个信号告诉他服务端正在努力为他提供报表中，不是挂了。 一些常见的性能问题分析 性能问题的定位和分析是性能测试的非常重要的组成部分。这里讨论一些常见的性能问题。 接口请求慢： 首先排查一下网络耗时。对与执行机来说，请求速度由多个环节组成。 首先要确认connect time。第一次握手、第一次DNS解析等操作都需要消耗较多的时间，因此部分接口在压测时可能会出现第一个请求很慢的情况。网络间通信是高connect time的主要产生原因。例如使用国内的aws向国外的aws发请求大概需要300ms做网络通信，减去这个时间才是服务器处理业务的时长。 HTTPS在保障了安全的同时，也增加了额外的请求时长。即使在同一网络中https也可能产生超过40ms的额外请求时长。 如果是业务本身速度慢，那就需要打日志或者观察