使用真实 Elasticsearch 进行更快的集成测试
2024年11月29日 | by mebius
作者:来自 ElasticPiotr Przybyl
了解如何使用各种数据初始化和性能改进技术加快 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 中观察到测试执行时间(包括数据初始化):
总结
在这篇文章中,我展示了使用 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 之外执行推理。这样你就可以使…