提高批量 HTTP REST 调用与 GET 方法调用并行的性能答案

【问题标题】：Boosting performance of bulk HTTP REST calls paralleling GET methods invocation提高批量 HTTP REST 调用与 GET 方法调用并行的性能
【发布时间】：2019-01-21 12:26:50
【问题描述】：

在我开发的应用程序中，我需要执行大量的 REST 调用。我需要与之交互的 REST API 资源的架构是分层的，如下所示：

/api/continents - return list of all Earth's continents
/api/continents/{continent_name}/countries - return list of all countries on mentioned continent
/api/continents/{continent_name}/countries/{country_name}/cities - return list of all cities in mentioned country

不幸的是，这个 API 没有提供任何方法来获取所有城市，我需要首先获取所有大陆的列表，然后获取每个大陆的所有国家的列表，然后获取所有城市的列表每个大陆的每个国家。

首先，我尝试实现从该 API 获取所有城市的方法，而无需并行化，仅通过连续调用。类似的东西：

private List<City> getCities() {
    List<Continent> continents = getAllContinents(); //HTTP GET call
    List<Country> countries = new ArrayList<>();
    for (Continent continent: continents) {
        countries.addAll(getAllCountriesOfContinent(continent));
    }
    List<City> cities = new ArrayList<>();
    for (Country country : countries) {
        cities.addAll(getAllCitiesOfCountry(country));
    }
    return cities;
}

但这种方法运行速度太慢（具体执行时间约为 7 小时）。我决定尝试使用 Java Parallel Streams 和 CompletableFuture 来改进它，并得到了这样的方法：

private List<City> getCities() {
    return getAllContinents()
        .parallelStream()
        .map(continent -> getAllCountriesOfContinent(continent))
        .flatMap(feature -> feature.join().parallelStream())
        .map(country -> getAllCitiesOfCountry(country))
        .flatMap(feature -> feature.join().parallelStream())
        .collect(Collectors.toList());
}

getAllCountriesOfContinent 和 getAllCitiesOfCountry 方法返回 CompletableFuture 列表的位置如下：

private CompletableFuture<List<Country>> getAllCountriesOfContinent(Continent continent) {
    return CompletableFuture.supplyAsync(() -> {
        return restClient.getDataFromApi(continent);
    });
}

private CompletableFuture<List<City>> getAllCitiesOfCountry(Country country) {
    return CompletableFuture.supplyAsync(() -> {
        return restClient.getDataFromApi(country);
    });
}

通过这样的重构，我得到了很好的性能提升（它执行了大约 25-30 分钟）。但我认为我可以使用 Java ThreadPoolExecutors 和 Threads 或 ForkJoin 框架对其进行更多改进。这些方法会帮助我提高代码的性能，还是有其他一些特殊的技术/算法/框架可以做到这一点？

【问题讨论】：

默认 CompletableFuture.supplyAsync 使用 fork join pool
几个问题，您使用的端点是否总是快速返回？您使用什么进行 HTTP get 调用？
@Welsh for HTTP 调用我使用的是 Apache HTTP 客户端，至于 API 的质量和速度 - 它非常一致和稳定。
@GlebKosteiko 只是确保您还确保您正在创建您的 HttpClient with multithreading 并且它不会在那里成为瓶颈。
感谢您的快速回归！

标签： java concurrency parallel-processing java-stream fork-join

【解决方案1】：

这些方法会帮助我提高性能吗？

答案是：可能。

你看，parallelStream() 为你提供了多线程的“默认”实现（在幕后，这个操作实际上使用了 ForkJoin 框架）。

换句话说：您总是可以退后一步，投入大量时间进行实验，使用不同的低级方法，并衡量相应的结果。是的，最有可能的是，当您花 1 周时间微调您的算法时，您应该最终能够得到比依赖 Java 必须提供的“默认实现”更好的东西。

但是你得到了多大的进步，以及你需要多长时间才能到达那里，这是很难预测的。

因此，真正的答案是：

衡量哪个操作需要多长时间，确定您的整体系统中的真正瓶颈（例如：典型客户是否应该在每个国家/地区使用一个线程来获取这些城市，或者更少的线程会更有帮助）
如果可能，请增强 REST API 以简单地为您提供城市列表

长话短说：您必须做出权衡。您可以编写大量自定义代码以获得更好的结果。但是没有人能提前告诉您您将获得的收益，以及由于“随着时间的推移编写和维护更复杂的代码”而将多少“成本”添加到您的“预算”中。

【讨论】：

默认的全局 forkjoin 池不打算用于阻塞操作，所以这不是最好的建议。使用自定义执行器并尝试不同大小的线程池也相当简单，所以我不确定每周的数小时工作从何而来。只要 API 可以处理，您可以通过使用更多线程来获得相当显着的改进。见reddit.com/r/java/comments/ai9nyf/…。代码几乎相同，应该运行得更快。代码不太正确，但应该很接近。

【解决方案2】：

我觉得多线程在这里并不完全是正确的工具，因为这是通过网络进行通信的问题，而不是计算问题。

特别是因为 Java 缺少协程，parallelStream 可能是一次管理多个运行中的 HTTP 请求的好且合理的选择，但它并不是您应该关注的解决方案中最重要的部分。

您应该关注的是网络详细信息，而不是 CPU 详细信息。这种情况尤其让我想起了 HTTP/2，它应该允许多个这样的请求同时进行。您还应该研究早期版本支持的 HTTP Pipelining，但设置起来要复杂得多。

【讨论】：