以每秒预定义的请求数使用 Locust

Question

查看负载测试工具，我发现 Locust 并立即发现它作为一个 Python 人很有吸引力，但我不完全确定我是否可以用它实现以下场景......

我的任务是使用真实流量对 REST API 进行负载测试。我从生产 Apache 日志中提取了 5 分钟的 GET 流量，其想法是使用负载测试工具以相同的时间分布（每秒 1 到 36 个请求）运行这些相同的请求。为此，我构建了一个 Python 字典，其中以相对时间戳（xx:xx，即 mins:secs）为键，以该秒请求的 URL 路径列表为值。

我们将某个时间点的生产数据库转储还原到我们的测试环境，请求来自创建转储之后的接下来的五分钟。在测试运行之间，我正在更改 REST API 如何连接到数据库的参数，因此测试运行需要尽可能相同，以使指标具有可比性。

我查看了 Locust 文档中的自定义负载形状，似乎它们可能有效，但我并不肯定。自定义tick方法实现能不能做到这一点：

在 0 秒时，发出一组 4 个请求。
在 1 秒时，发出一组 2 个请求。
在 2 秒时，发出一组 12 个请求。
...时间流逝，每秒都会发生一组预定义的请求...
在 4 分 59 秒时，发出一组 27 个请求。
在 5 分钟后，发出一组 14 个请求。

这将如何映射到 Locust 的能力？产生多少用户并不重要，重要的是发出了多少请求，以及在什么时间点发出的。

我真的很喜欢 Locust 的易用性和熟悉的语法，但它是否适合使用这样的静态、可重复请求负载进行测试？

编辑： 似乎这种方法在没有很大困难（或根本没有）的情况下可能无法实现，我想出了另一种方法，其不同之处足以保证一个单独的问题：@987654321 @

Answer 1

简而言之，没有。 Locust 的核心是运行一定数量的用户，并且这些用户彼此相当独立。

您可以使用wait_time = constant_throughput(x) (https://docs.locust.io/en/stable/writing-a-locustfile.html#wait-time-attribute) 控制每个用户的吞吐量。您还可以查看针对全局吞吐量 (https://github.com/SvenskaSpel/locust-plugins/blob/master/examples/constant_total_ips_ex.py) 的 locust-plugins 的 constant_total_ips。

但是如果你想在一个确切的时间做一个 exact 数量的请求，我认为没有什么现成的。

您可以在触发请求之前使用 python 来“同步”所有用户。我没有一个很好的解决方案，但这有点工作（虽然你需要运行 10 个用户，否则你会遇到并发问题 - 很确定那里有更好的解决方案）

users_waiting = 0
lock = Semaphore(10)
...
    @task
    def t(self):
        global users_waiting
        with lock:
            users_waiting = users_waiting + 1 if users_waiting < 10 else 1
            while self.environment.runner and users_waiting < 10:
                time.sleep(0.1)
            # actually do your requests here

Answer 2

你想要的是custom Load Shape。您可以在代码中定义您希望 Locust 在任何给定时刻执行的操作。文档中的示例：

class MyCustomShape(LoadTestShape):
    time_limit = 600
    spawn_rate = 20

    def tick(self):
        run_time = self.get_run_time()

        if run_time < self.time_limit:
            # User count rounded to nearest hundred.
            user_count = round(run_time, -2)
            return (user_count, spawn_rate)

        return None

但在您的情况下，您可以从字典中提取值，而不是 user_count = round(run_time, -2)。如果您使user_count 和spawn_rate 相同，则下一个效果将大致与您每次的用户数量无关（假设您有足够的工人能够每次都产生差异）。如果需要，调整spawn_rate 可以调整和消除差异，从而减少用户的突然变化。