13

我开发了一个客户端-服务器风格、基于数据库的系统,我需要设计一种方法来对系统进行压力/负载测试。客户不可避免地想知道这样的事情:

• 一台服务器可以支持多少客户端?
• 服务器可以支持多少并发搜索?
• 我们可以在数据库中存储多少数据?
• ETC。

所有这些问题的关键是响应时间。我们需要能够测量响应时间和性能如何随着新负载的引入而下降,以便我们可以生成某种漂亮的图表,我们可以将其扔给客户,让他们了解在给定的情况下期望什么样的性能硬件配置。

现在,我们只是伸出手指,根据我们从经验中对系统的了解做出有根据的猜测。随着产品被置于更苛刻的条件下,这被证明不足以满足我们未来的需求。

我的任务是设计一种以有意义的方式获得此类答案的方法。我意识到这不是任何人都可以明确回答的问题,但我正在寻找有关人们如何在自己的系统上进行此类工作的建议。

需要注意的一点是,我们可以通过 Python 语言(由 SWIG 提供)完全访问我们的客户端 API,这比 C++ 更容易用于此类工作。

所以我们开始了,我把这个扔到地板上:真的很想看看你们能想出什么主意!

4

5 回答 5

9

测试 1:像 mad 一样连接和断开客户端,看看你如何处理会话的初始化和结束,以及你的服务器在峰值下能存活多少,同时测量有多少客户端无法连接。这是非常重要的

测试 2:连接客户端并让他们保持登录状态一周,做随机动作(FuzzTest)。计算每个动作的往返时间。还要记录操作的顺序,因为这样你的“客户”会在你的用例中发现漏洞(非常重要,而且很难理性地测试)。

测试 3 和 4:确定系统的主要用例,并编写执行这些任务的脚本。然后运行几个执行相同任务的客户端(测试 3),以及执行不同任务的几个客户端(测试 4)。

系列: 现在您需要的另一个维度是客户数量。一个不错的系列是:5,10,50,100,500,1000,5000,10000,...

通过这种方式,您可以获得具有不同工作负载的每个系列测试的数据。

也恭喜您将您的客户 api 转换为 Python!这是做好准备的好方法。

注意:IBM 有一个 Java 模糊测试样本,这对您的情况不适用,但会帮助您为您的系统设计一个好的模糊测试

于 2008-11-07T11:44:40.333 回答
7

如果你习惯用 Python 编写测试代码,我发现funkload非常有能力。您没有说您的服务器是基于 http 的,因此您可能必须调整他们的测试工具以适应您自己的客户端/服务器风格。

一旦你在 Python 中进行了测试,funkload 可以在多个线程上运行它,监控响应时间,并在测试结束时为你总结。

于 2008-11-07T11:55:19.017 回答
5

对于性能,您关注两件事:延迟(应用程序的响应能力)和吞吐量(每个间隔有多少操作)。对于延迟,您需要有一个可接受的基准。对于吞吐量,您需要具有可接受的最小吞吐量。

这些是你的起点。为了告诉客户每个间隔可以做多少 xyz,那么您将需要了解硬件和软件配置。了解生产硬件对于获得准确的数据很重要。如果您不知道硬件配置,那么您需要设计一种方法将您的数据从测试硬件映射到最终的生产硬件。

如果没有硬件知识,那么您实际上只能观察性能随时间的趋势,而不是绝对的。

了解软件配置同样重要。您是否有集群服务器配置,是否负载平衡,服务器上是否运行其他任何东西?您可以扩展您的软件还是必须扩展硬件以满足需求。

要了解您可以支持多少客户,您需要了解什么是标准操作集。一个快速的测试是删除客户端并编写一个存根客户端,然后尽可能多地启动这些客户端。让每一个连接到服务器。您最终将达到服务器连接资源限制。如果没有连接池或更好的硬件,您将无法获得比这更高的值。通常,您会在此之前遇到架构问题,但无论哪种情况,您都有上限。

获取这些信息并设计一个您的客户可以执行的脚本。您需要将脚本执行操作所需的时间与预期用户执行操作所需的时间进行映射。如上所述开始增加您的数量,以达到客户增加导致性能下降更大的程度。

压力测试有很多方法,但关键是了解预期负载。询问您的客户他们的期望。每个间隔的预期需求是多少?从那里你可以计算出高负荷。

您可以对许多连续运行数小时或数天的客户进行浸泡测试。您可以尝试尽可能快地连接尽可能多的客户端,以查看您的服务器如何处理高需求(也是 DOS 攻击)。

并发搜索应该通过代表客户端的标准行为搜索来完成,或者编写脚本来建立一个等待多个线程的信号量,然后您可以一次释放它们。这很有趣并且会惩罚您的数据库。执行搜索时,您需要考虑可能存在的任何缓存层。您需要测试缓存和不缓存(在每个人都提出唯一搜索请求的情况下)。

数据库存储基于物理空间;您可以根据字段长度和预期数据填充来确定行大小。统计推断或创建数据生成脚本(对您的负载测试场景很有用,应该是您组织的资产),然后将生成的数据映射到业务对象。您的客户会关心他们可以存储多少“业务对象”,而您会关心可以存储多少原始数据。

其他需要考虑的事项:预期可用性是多少?让服务器联机需要多长时间。如果需要两天时间才能恢复在线,那么 99.9% 的可用性并不好。另一方面,如果重新启动需要 5 秒并且您摔倒了,那么较低的可用性更容易接受。

于 2008-11-07T12:25:41.200 回答
0

如果您有预算,LoadRunner 将是完美的选择。

于 2008-11-07T12:16:08.130 回答
0

相关说明:Twitter 最近开源了他们的负载测试框架。可能值得一试:)

于 2012-07-10T05:04:21.383 回答