如何为网站设计负载测试?

Ret*_*ons 4 load jmeter performance-testing

我最近一直在考虑如何在我们将它们发布之前测试我们的webapps的性能.我知道我们无法复制此测试的实际用户活动,因为它是新功能.我可以通过查看我们的日志来猜测用户活动,并相应地创建测试,但我想知道这将实现什么.

我很想知道如何:

  1. 确定负载和
  2. 确定行为

与现实世界的情景相比,这会让你有多远?

zer*_*eux 5

很多问题.我们公司已经运行了几年的基准测试和负载测试,主要是基于HTTP的.

在进入复杂场景之前,我们通常从基于Apache Bench的简单基准开始(与Apache捆绑的'ab'命令).这不是负载测试而是性能测试,因为生成的客户端实际上等待HTTP查询完成,然后继续下一个.基本思路是尝试'ab -c N -t 30',其中N = 1,2,4,8,50,100(例如).您可以快速了解可预期的可扩展性和最大吞吐量.

注意:在测试服务器附近运行'ab'命令(理想情况是在同一个LAN上),否则你也会在网络上进行测试(延迟是这里的主要问题).但在某些商业案例中,这是真正需要测试的整个系统(服务器+网络).

从这里开始,如果结果看起来很好(即,througput扩展到服务器端的处理器数量,低或零错误率),我们继续进行负载测试.否则,我们会搜索瓶颈,因为负载测试只会确认可伸缩性问题,并且一旦负载大于支持的吞吐量(500个内部错误的100%,连接丢失,大型时钟,服务器抖动等),最有可能显示可怕的结果.

顺便说一句,通过负载测试,我的意思是使用可以应用给定服务器/应用程序的任何负载的工具,尤其是服务器无法处理的负载(例如:Jmeter,Tsung).负载测试中非常有趣的是观察服务器过载时发生的情况.当您选择性能不合理的确切测试点时,确定服务器可以处理的最大负载取决于您.

然后是猜测或观察现有模式的问题.在许多情况下,我们被要求对新网站进行负载测试,显然没有观察到真实的行为.否则,您可以使用分析并观察前十页:您的场景至少应该遍历它们.你会想要一些导航路径:

  • 显然到达主页
  • 使用搜索功能并从一个内容弹回到另一个内容,可能是随机的
  • 如果该功能存在,请继续登录
  • 更常见的是POST表单,只有读取/ GET数据的loadtest不是很有意义

其他提示:

  • 避免复杂性; 例如,如果您有购物车,则无需使用付款等设置真实的购物场景.在电子商务商店,购物车路径很少是性能问题,95%的流量在其他地方(浏览产品等).
  • 在一个大的负载测试节日中将它们堆积起来之前逐个测试导航路径; 他们应事先单独提供好的结果
  • 最好能够解决许多真正运用缓存的路径(总有缓存:HTTP,app,SQL,文件系统等); 生成动态场景的工具是必须的,您可以从长列表中更改登录名或对象ID

总的想法是从简单的测试开始逐步进行,否则如果它们不适合完美的可扩展性曲线,你将很难解释结果.你猜怎么着?它们从未适合完美的可扩展性曲线......