jkp*_*jkp 12 python database client-server stress-testing load-testing
我开发了一个客户端 - 服务器风格,基于数据库的系统,我需要设计一种压力/负载测试系统的方法.客户不可避免地想要了解以下内容:
•服务器可以支持多少客户端？
•服务器支持多少并发搜索？
•我们可以在数据库中存储多少数据？
•等
所有这些问题的关键是响应时间.我们需要能够测量响应时间和性能如何随着新负载的引入而降低,这样我们就可以生成一些我们可以抛给客户端的漂亮图表,让他们知道给定的性能是什么样的.硬件配置.
现在我们只是把手指放在空中,并根据我们从经验中已经了解的系统做出有根据的猜测.由于产品处于更苛刻的条件下,这证明不足以满足我们未来的需求.
我被赋予了设计方法以有意义的方式获得这些答案的任务.我意识到这不是任何人都可以肯定地回答的问题,但我正在寻找有关人们如何在自己的系统上进行此类工作的建议.
需要注意的一点是,我们可以通过Python语言(SWIG提供)完全访问我们的客户端API,这比使用C++更容易使用这种工作.
所以我们去了,我把它扔到了地板上:真的很有兴趣看看你们有什么想法可以想出来!
测试1:疯狂地连接和断开客户端,看看你处理init和会话结束的程度,以及你的服务器在尖峰下能够存活多少,同时这样做可以衡量有多少客户端无法连接.这非常重要
测试2:连接客户端并保持他们登录一周,进行随机操作(FuzzTest).计算每次行动的往返时间.同时记录行动的顺序,因为这样你的"客户"会发现你的用例存在漏洞(非常重要,非常难以合理地测试).
测试3和4:确定系统的主要用例,并编写执行这些任务的脚本.然后运行几个执行相同任务的客户端(测试3),以及几个执行不同任务的客户端(测试4).
系列: 现在您需要的另一个维度是客户数量.一个很好的系列将是:5,10,50,100,500,1000,5000,10000,...
这样,您可以获得具有不同工作负载的每个测试系列的数据.
也祝贺你的客户api到Python!这是让事情准备就绪的好方法.
注意:IBM有一个关于Java的模糊测试示例,这对您的案例是不实际的,但会帮助您为系统设计一个很好的模糊测试
对于性能,您要考虑两件事:延迟(应用程序的响应性)和吞吐量(每个间隔有多少操作).对于延迟,您需要具有可接受的基准.对于吞吐量,您需要具有最低可接受的吞吐量.
这些是你的起点.为了告诉客户每个间隔可以执行多少xyz,那么您将需要了解硬件和软件配置.了解生产硬件对于获得准确数据非常重要.如果您不知道硬件配置,那么您需要设计一种方法将数字从测试硬件映射到最终的生产硬件.
在没有硬件知识的情况下,您实际上只能观察到性能随时间而非绝对的趋势.
了解软件配置同样重要.您是否有群集服务器配置,是否负载均衡,服务器上是否还有其他运行？您可以扩展您的软件,还是必须扩展硬件以满足需求.
要了解您可以支持的客户数量,您需要了解什么是标准操作集.快速测试是删除客户端并编写存根客户端,尽可能多地启动客户端.让每个人连接到服务器.您最终将达到服务器连接资源限制.没有连接池或更好的硬件,你不能高于此.通常你会在这之前遇到一个架构问题但在任何一种情况下你都有一个上限.
获取此信息并设计客户端可以制定的脚本.您需要映射脚本执行操作所需的时间,以及预期用户执行操作所需的时间.如上所述,开始增加您的数字,以达到客户端增加导致性能下降的程度.
有很多方法可以进行压力测试,但关键是要了解预期的负载.向您的客户询问他们的期望.每个区间的预期需求是多少？从那里你可以计算出上部负荷.
您可以对许多客户连续运行数小时或数天进行浸泡测试.您可以尽可能快地连接尽可能多的客户端,以查看服务器处理高需求(也是DOS攻击)的程度.
并发搜索应该通过代表客户端执行的标准行为搜索来完成,或者编写脚本来建立等待许多线程的信号量,然后您可以一次性释放它们.这很有趣并且会惩罚您的数据库.执行搜索时,您需要考虑可能存在的任何缓存层.您需要测试缓存和缓存(在每个人都发出唯一搜索请求的情况下).
数据库存储基于物理空间; 您可以根据字段长度和预期数据填充来确定行大小.从统计上推断出来或创建数据生成脚本(对于负载测试场景非常有用,应该是组织的资产),然后将生成的数据映射到业务对象.您的客户将关心他们可以存储多少"业务对象",同时您将关心可以存储多少原始数据.
其他需要考虑的事项:预期的可用性是多少？将服务器联机需要多长时间呢？99.9%的可用性是不好的,如果需要两天的时间才能恢复在线状态.另一方面,如果重启需要5秒钟并且您有倒下,则可接受性较低.