PySurge

拥有现有的Python代码？想快速用它来设置一些简单的性能测试？试试PySurge，这是一个基于Python的工具，允许您快速在Python中编写简单的性能测试。

示例

查看此项目的示例，了解如何快速配置和执行简单的HTTP负载测试。

安装

该项目可在PyPI上获得

pip install pysurge

在Python中进行性能测试...？

是的，Python在并发和扩展方面有其局限性。然而，有时您不需要比Python提供的更多扩展。这尤其适用于测试基于云的应用程序，这些应用程序“扩展”（即，在需求增加时启动更多副本）。可以在单个副本上以较低规模进行负载测试，并将结果外推。

现在有很多复杂性能测试工具，旨在在非常高的扩展级别上对应用程序进行负载测试。该项目旨在为那些不需要大规模扩展的人提供一个“快速且简单”的解决方案。您能实现的扩展当然受测试需求、Python的并发缺点（即GIL）和您的硬件规格（CPU核心数是一个关键因素）的限制。

许多测试工程师已经编写了Python代码。该项目的目标是防止工程师需要大量重写他们的逻辑，才能在更高的扩展级别上运行。如果代码是线程安全的，则可以使用PySurge导入和并发执行。

PySurge是如何工作的？

编写TestCase类

测试由测试编写者定义，继承自 pysurge.TestCase 类，并具有以下功能：

• startup 和 shutdown —— 这些定义了“会话”级别的设置和清理任务，这些任务将在每个测试用例类中只发生一次。在这里，您还可以定义所有触发的测试实例将共享的变量/函数等。
• setup 和 teardown —— 定义“测试”级别的设置和清理任务，这些任务将针对每个被触发的唯一测试实例执行。
• run —— 定义实际的测试运行逻辑。
• __init__ 也可以定义自定义的 kwargs —— 如果您想稍微调整测试的行为，这非常有用。

测试指标

测试用例类可以存储在名为 self.metrics 的字典中的浮点数/整数指标。例如，您可能希望存储一个指标，每次测试触发时都会跟踪您的服务的“响应时间”。在您的测试的 run 函数中，您可能有如下代码：

start_time = time.time()
do_stuff()
end_time = time.time()
self.metrics['response_time'] = end_time - start_time

在测试运行结束时，存储在每个触发的实例中的指标会被平均并报告。

配置 pysurge 运行

pysurge 使用 YAML 配置文件，该文件定义了

• 您想要运行的测试类
• 触发它们的速率（每秒测试数量）
• 应传递给 TestCase.__init__ 的任何 kwargs —— 如果您想同时运行相同的测试类但具有不同的选项，这很有用。

启动运行

您可以使用以下方式启动测试运行：

$ pysurge -c </path/to/config.yaml> -d <run duration in minutes>

运行期间会发生什么？

为了尽可能有效地使用线程池，pysurge 使用 multiprocessing 为您系统上的每个可用 CPU 核心创建一个子进程。每个子进程内为每个 TestClass 创建一个线程池，然后将测试“触发速率”平均分配给每个子进程。例如，如果您定义了一个名为 MyTest 的测试用例，该测试用例应“每秒触发一次”，并且您有 4 个 CPU 核心，以下将发生：

• 将创建四个子进程
• 在每个子进程中创建一个线程池，运行 MyTest 中的代码
• 每个线程池将以“每 4 秒触发一次”的速率触发测试
• 每个子进程将使其测试触发的开始时间错开 1 秒，以使“触发速率”均匀。

一旦测试运行“提升”并且所有线程池都已开始触发，这将导致 MyTest 每秒触发一个实例。

随着您添加更多的测试类，每个子进程中将添加更多的线程池。子进程的数量将保持不变。

由于测试是在线程池中执行的，因此它们不能过于占用 CPU 资源——理想的选择是快速 I/O 绑定测试，与远程 API/服务交互。测试应该注意高效使用 CPU 资源——也就是说，专注于 I/O 绑定任务（如与远程网络服务交互）并记得在循环中“睡眠”，以避免消耗 CPU 周期。

停止运行

您可以发送 SIGINT/ctrl+C 来提前结束运行。这不会突然结束应用程序，而是触发所有子进程开始干净地关闭。否则，运行将执行运行时指定的 duration。

查看结果

pysurge 将所有运行线程的日志输出到 stdout

它还会在其运行结束时生成一个基本的报告。

以下示例是针对名为 UploadTest 的测试。配置了两个此测试实例以运行

• UploadTest 没有kwargs
• UploadTest 有 kwargs legacy=True

每次测试运行时，都会存储一个名为 upload->db_time_in_sec 的指标。平均时间会在报告中显示。

2018-09-14 18:51:37,590 MainProcess MainThread INFO ---- Results for test '<UploadTest kwargs={}> -- upload test, legacy: False' ----
2018-09-14 18:51:37,590 MainProcess MainThread INFO >>> Ran for 1849.129022 sec, fired 6988 total tests
2018-09-14 18:51:37,590 MainProcess MainThread INFO >>> Successes: 6987, failures: 1
2018-09-14 18:51:37,591 MainProcess MainThread INFO ---- Metrics for test '<UploadTest kwargs={}> -- upload test, legacy: False' ----
2018-09-14 18:51:37,591 MainProcess MainThread INFO >>> upload->db_time_in_sec: 2.668292
2018-09-14 18:51:37,591 MainProcess MainThread INFO
2018-09-14 18:51:37,591 MainProcess MainThread INFO ---- Results for test '<UploadTest kwargs={'legacy': True}> -- upload test, legacy: True' ----
2018-09-14 18:51:37,591 MainProcess MainThread INFO >>> Ran for 1849.129022 sec, fired 7004 total tests
2018-09-14 18:51:37,591 MainProcess MainThread INFO >>> Successes: 7002, failures: 2
2018-09-14 18:51:37,591 MainProcess MainThread INFO ---- Metrics for test '<UploadTest kwargs={'legacy': True}> -- upload test, legacy: True' ----
2018-09-14 18:51:37,591 MainProcess MainThread INFO >>> upload->db_time_in_sec: 1.025963
2018-09-14 18:51:37,591 MainProcess MainThread INFO

pysurge 不做什么？

• 非常大的规模测试
• 分布式负载测试（在多个主机上编排和运行测试）
• 高级报告