当前实现 - 将原始文件划分为与服务器数量相等的文件。确保每台服务器选择一个文件进行处理。每台服务器将文件拆分为 90 个桶。使用 ForkManager 分叉 90 个进程，每个进程在一个存储桶上运行。子进程将进行 API 调用。合并子进程的输出。合并每个服务器的输出。
Stats - 使用 API 调用下载的内容大小为 40KB。在 2 台服务器上，225k 用户文件的上述过程在 15 分钟内运行。我的目标是在 30 分钟内完成一个 1000 万个文件。（希望这听起来不荒谬！）
我曾考虑使用 BerkeleyDB，但找不到如何将 BerkeleyDB 文件转换为普通的 ASCII 文件。
对我来说，这听起来像是一次性手术。虽然我不明白 30 分钟的限制，但我有一些我从经验中知道的建议。
首先，正如我在评论中所说，您的瓶颈不会是从文件中读取数据。它也不会将结果写回硬盘。瓶颈将在于您的机器和远程机器之间的传输。您的设置听起来很复杂，但在这种情况下可能对您没有帮助。
如果您正在访问 Web 服务，则有人正在运行该服务。有些服务器只能处理一定数量的负载。我在晚上运行的负载测试非常小，已经关闭了一家大型物流公司的开发环境服务器。通常，这些东西是为长期负载而配备的，而不是短期的重负载。
由于 IT 就是通过各种协议（如 Web 服务或其他 API）相互交谈，因此您还应该考虑只与运行该服务的人交谈。如果您有业务关系，那很容易。如果没有，请尝试找到联系他们的方法，并询问他们的服务是否能够处理如此多的请求。您最终可能会被他们永久排除在外，因为对于他们的管理员来说，您似乎试图对他们进行DDOS。
我会问他们您是否可以向他们发送文件（或数据的摘录，减少与处理相关的内容），以便他们可以批量进行操作。这样，您就可以消除将所有内容作为 Web 请求处理的负载，以及执行这些请求所需的时间。