使用真实 Elasticsearch 进行更快的集成测试

2024年11月29日   |   by mebius

作者:来自 ElasticPiotr Przybyl

%title插图%num

了解如何使用各种数据初始化和性能改进技术加快 Elasticsearch 的自动化集成测试速度。

在本系列的第 1 部分中,我们探讨了如何编写集成测试,让我们能够在真实的 Elasticsearch 环境中测试软件,并非难事。本文将演示各种数据初始化和性能改进的技术。

不同的目的,不同的特点

一旦测试基础设施设置完毕,并且项目已经使用集成测试框架进行至少一个测试(例如我们在演示项目中使用 Testcontainers),添加更多测试就变得很容易,因为它不需要模拟。例如,如果你需要验证 1776 年获取的书籍数量是否正确,你只需添加一个测试,如下所示:

@Test
void shouldFetchTheNumberOfBooksPublishedInGivenYear() {
    var systemUnderTest = new BookSearcher(client);
    int books = systemUnderTest.numberOfBooksPublishedInYear(1776);
    Assertions.assertEquals(2, books, "there were 2 books published in 1776 in the dataset");
}

只要用于初始化 Elasticsearch 的数据集已包含相关数据,这就足够了。创建此类测试的成本很低,维护它们几乎毫不费力(因为它主要涉及更新 Docker 镜像版本)。

没有软件是独立存在的

如今,我们编写的每一个软件都与其他系统相连。虽然使用模拟的测试非常适合验证我们正在构建的系统的行为,但集成测试让我们确信整个解决方案能够按预期运行并将继续如此。这可能会让我们忍不住添加越来越多的集成测试。

集成测试有其成本

然而,集成测试并非免费。由于其性质 —— 超越了仅在内存中的设置 —— 它们往往更慢,从而浪费我们的执行时间。

平衡收益(集成测试带来的信心)与成本(测试执行时间和计费,通常直接转化为云供应商的发票)至关重要。我们可以让它们运行得更快,而不是因为测试速度慢而限制测试数量。这样,我们可以在添加更多测试的同时保持相同的执行时间。本文的其余部分将重点介绍如何实现这一点。

让我们重新回顾一下我们迄今为止使用的示例,因为它非常慢并且需要优化。对于本次和后续实验,我假设 Elasticsearch Docker 映像已被提取,因此不会影响时间。另外,请注意,这不是一个合适的基准,而是一个一般准则。

利用 Elasticsearch 的测试也可以从性能提升中受益

Elasticsearch 经常被选为搜索解决方案是因为其高性能表现。开发人员通常会非常谨慎地优化生产代码,尤其是在关键路径上。然而,测试通常被视为次要,导致测试运行缓慢,以至于很少有人愿意运行测试。但情况并不一定要如此。通过一些简单的技术调整和方法上的改变,集成测试可以运行得更快。

让我们从当前的集成测试套件开始。该测试套件按预期运行,但仅运行三个测试时,通过执行 time ./mvnw test '-Dtest=*IntTest*' 需要耗时五分半钟 —— 每个测试大约 90 秒。请注意,你的结果可能会因硬件、网络速度等因素而有所不同。

如果可以,请批量处理

在集成测试套件中,许多性能问题源于数据初始化效率低下。虽然某些流程在生产流程中可能是自然的或可接受的(例如,数据在用户输入时到达),但这些流程可能不是测试的最佳选择,因为我们需要快速批量导入数据。

我们示例中的数据集约为 50 MiB,包含近 81,000 条有效记录。如果我们单独处理和索引每条记录,我们最终会发出 81,000 个请求,只是为了为每个测试准备数据。

而不是像在主分支中那样使用简单的循环逐个索引文档:

boolean hasNext = false;
do {
    try {
        Book book = it.nextValue();
        client.index(i -> i.index("books").document(book));
        hasNext = it.hasNextValue();
    } catch (JsonParseException | InvalidFormatException e) {
        // ignore malformed data
    }
} while (hasNext);

我们应该使用批处理方法,例如使用 BulkIngester。这允许并发索引请求,每个请求发送多个文档,从而大大减少请求数量:

try (BulkIngester> ingester = BulkIngester.of(bi -> bi
    .client(client)
    .maxConcurrentRequests(20)
    .maxOperations(5000))) {

    boolean hasNext = true;
    while (hasNext) {
        try {
            Book book = it.nextValue();
            ingester.add(BulkOperation.of(b -> b
                .index(i -> i
                    .index("books")
                    .document(book))));
            hasNext = it.hasNextValue();
        } catch (JsonParseException | InvalidFormatException e) {
            // ignore malformed data
        }
    }
}

这一简单的改变将整体测试时间缩短至 3 分 40 秒左右,即每次测试大约 73 秒。虽然这是一个不错的改进,但我们可以进一步改进。

保持本地化

我们在上一步中通过限制网络往返缩短了测试时长。在不改变测试本身的情况下,我们是否可以消除更多的网络调用?

让我们回顾一下当前的情况:

  • 在每次测试之前,我们都会反复从远程位置获取测试数据。
  • 在获取数据时,我们会将其批量发送到 Elasticsearch 容器。

我们可以通过将数据尽可能靠近 Elasticsearch 容器来提高性能。还有什么比容器本身更近呢?

将数据批量导入 Elasticsearch 的一种方法是 _bulk REST API,我们可以使用 curl 调用它。此方法允许我们发送以换行符分隔的 JSON 格式编写的大型有效负载(例如,来自文件)。格式如下所示:

action_and_meta_datan
optional_sourcen
action_and_meta_datan
optional_sourcen
....
action_and_meta_datan
optional_sourcen

确保最后一行为空。

在我们的例子中,文件可能如下所示:

{"index":{"_index":"books"}}
{"title":"...","description":"...","year":...,"publisher":"...","ratings":...}
{"index":{"_index":"books"}}
{"ttgcodeitle":"Whispers of the Wicked Saints","description":"Julia ...","author":"Veronica Haddon","year":2005,"publisher":"iUniverse","ratings":3.72}

理想情况下,我们可以将这些测试数据存储在一个文件中,并将其包含在存储库中,例如 src/test/resources/。如果这不可行,我们可以使用简单的脚本或程序从原始数据生成文件。例如,请查看演示存储库中的 CSV2JSONConverter.java

一旦我们在本地有了这样的文件(这样我们就消除了获取数据的网络调用),我们就可以解决另一点,即:将文件从运行测试的机器复制到运行 Elasticsearch 的容器中。这很容易,我们可以在定义容器时使用单个方法调用 withCopyToContainer 来做到这一点。所以更改后它看起来像这样:

@Container
ElasticsearchContainer elasticsearch =
    new ElasticsearchContainer(ELASTICSEARCH_IMAGE)
        .withCopyToContainer(MountableFile.forHostPath("src/test/resources/books.ndjson"), "/tmp/books.ndjson");

最后一步是从容器内部发出请求,将数据发送到 Elasticsearch。我们可以通过在容器内运行 curl 来使用 curl 和 _bulk 端点执行此操作。虽然这可以在 CLI 中使tgcode用 docker exec 完成,但在我们的 @BeforeEach 中,它变成了 elasticsearch.execInContainer,如下所示:

ExecResult result = elasticsearch.execInContainer(
    "curl", "https://localhost:9200/_bulk?refresh=true", "-u", "elastic:changeme",
    "--cacert", "/usr/share/elasticsearch/config/certs/http_ca.crt",
    "-X", "POST",
    "-H", "Content-Type: application/x-ndjson",
    "--data-binary", "@/tmp/books.ndjson"
);
assert result.getExitCode() == 0;

从顶部开始,我们以这种方式向 _bulk 端点发出 POST 请求(并等待刷新完成),使用默认密码以用户 elastic 进行身份验证,接受自动生成的自签名证书(这意味着我们不必禁用 SSL/TLL),有效负载是 /tmp/books.ndjson 文件的内容,该文件在启动时复制到容器中。这样,我们减少了频繁网络调用的需要。假设 books.ndjson 文件已经存在于运行测试的机器上,则总持续时间减少到 58 秒。

少(通常)即是多

在上一步中,我们减少了测试中与网络相关的延迟。现在,让我们解决 CPU 使用率问题。

依赖 @Testcontainers 和 @Container 注释并没有错。但关键是要了解它们的工作原理:当你使用 @Container 注释实例字段时,Testcontainers 将为每个测试启动一个新容器。由于容器启动不是免费的(它需要时间和资源),所以我们要为每个测试支付这笔费用。

在某些情况下(例如,测试系统启动行为时),为每个测试启动一个新容器是必要的,但在我们的例子中不是。我们不必为每个测试启动一个新容器,而是为所有测试保留相同的容器和 Elasticsearch 实例,只要我们在每次测试之前正确重置容器的状态即可。

首先,将容器设为静态字段。接下来,在创建 books 索引(通过定义映射)并用文档填充它之前,如果现有索引来自之前的测试,请删除它。

因此,setupDataInContainer() 应该以类似以下内tgcode容开头:

ExecResult result = elasticsearch.execInContainer(
   "curl", "https://localhost:9200/books", "-u", "elastic:changeme",
   "--cacert", "/usr/share/elasticsearch/config/certs/http_ca.crt",
   "-X", "DELETE"
);
// we don't check the result, because the index might not have existed

// now we create the index and give it a precise mapping, just like for production
result = elasticsearch.execInContainer(
   "curl", "https://localhost:9200/books", "-u", "elastic:changeme",
   "--cacert", "/usr/share/elasticsearch/config/certs/http_ca.crt",
   "-X", "PUT",
   "-H", "Content-Type: application/json",
   "-d", """
       {
         "mappings": {
           "properties": {
             "title": { "type": "text" },
             "description": { "type": "text" },
             "author": { "type": "text" },
             "year": { "type": "short" },
             "publisher": { "type": "text" },
             "ratings": { "type": "half_float" }
           }
         }
       }
       """
);
assert result.getExitCode() == 0;

如你所见,我们可以使用 curl 在容器内执行几乎任何命令。这种方法有两个显著的​​优势:

  • 速度:如果有效负载(如 books.ndjson)已经在容器内,我们就不需要重复复制相同的数据,从而大大缩短了执行时间。
  • 语言独立性:由于 curl 命令与测试的编程语言无关,因此它们更容易理解和维护,即使对于那些可能更熟悉其他技术堆栈的人来说也是如此。

虽然使用原始 curl 调用对于生产代码来说并不理想,但它是测试设置的有效解决方案。尤其是与单个容器启动结合使用时,这种方法将我的测试执行时间缩短到大约 30 秒。

还值得注意的是,在演示项目(分支 data-init)中,目前只有三个集成测试,大约一半的总持续时间花在容器启动上。初始预热后,每个测试大约需要 3 秒钟。因此,再添加三个测试不会使总时间增加一倍至 30 秒,而只会增加大约 9-10 秒。可以在 IDE 中观察到测试执行时间(包括数据初始化):

%title插图%num

总结

在这篇文章中,我展示了使用 Elasticsearch 进行集成测试的几项改进:

  • 集成测试可以在不改变测试本身的情况下运行得更快 —— 只需重新考虑数据初始化和容器生命周期管理。
  • Elasticsearch 应该只启动一次,而不是每次测试都启动一次。
  • 当数据尽可能接近 Elasticsearch 并高效传输时,数据初始化效率最高。
  • 虽然减少测试数据集大小是一种明显的优化(这里没有介绍),但有时并不切实际。因此,我们专注于展示技术方法。

总体而言,我们显著缩短了测试套件的持续时间 —— 从 5.5 分钟缩短到 30 秒左右 —— 降低了成本并加快了反馈循环。

在下一篇文章中,我们将探索更先进的技术,以进一步减少 Elasticsearch 集成测试的执行时间。

如果你的案例使用了上述技术之一,或者你在我们的讨论论坛社区 Slack 频道上有任何疑问,请告诉我们。

准备好自己尝试一下了吗?开始免费试用

想要获得 Elastic 认证吗?了解下一期 Elasticsearch 工程师培训何时举行!

原文:Faster integration tests with real Elasticsearch – Search Labs

文章来源于互联网:使用真实 Elasticsearch 进行更快的集成测试

相关推荐: Elasticsearch 开放 inference API 为 Hugging Face 添加了原生分块支持

作者:来自 ElasticMax Hniebergall 借助 Elasticsearch 开放推理 API,你可以使用 Hugging Face 的推理端点(Inference Endpoints)在 Elasticsearch 之外执行推理。这样你就可以使…

Tags: , , , , ,