我正在尝试让 Tika 解析数以千万计的办公文件。Pdfs、docs、excels、xmls等。种类繁多。
吞吐量非常重要。我需要能够在合理的时间内解析这些文件,但同时,准确性也很重要。我希望不到 10% 的文档解析失败。(我所说的失败是指由于 tika 稳定性而失败,例如解析时超时。我不是指由于文档本身而失败)。
我的问题 - 如何在容器化环境中配置 Tika Server 以最大化吞吐量?
我的环境:
- 我正在使用 Openshift。
- 每个 tika 解析 pod 有CPU: 2 cores to 2 cores和 Memory: 8 GiB to 10 GiB。
- 我有 10 个 tika 解析 pod 副本。
在每个 pod 上,我运行一个 java 程序,其中有 8 个解析线程。
每个线程:
- 启动单个 tika 服务器进程(在 spawn 子模式下)
- Tika 服务器参数:
-s -spawnChild -maxChildStartupMillis 120000 -pingPulseMillis 500 -pingTimeoutMillis 30000 -taskPulseMillis 500 -taskTimeoutMillis 120000 -JXmx512m -enableUnsecureFeatures -enableFileUrl
- Tika 服务器参数:
- 该线程现在将不断地从 files-to-fetch 队列中抓取一个文件并将其发送到 tika 服务器,当没有更多文件要解析时停止。
这些文件中的每一个都本地存储在 pod 中的缓冲区中,因此使用本地文件优化:
它使用的 Tika 网络服务是:
Endpoint: `/rmeta/text`
Method: `PUT`
Headers:
- writeLimit = 32000000
- maxEmbeddedResources = 0
- fileUrl = file:///path/to/file
文件不大于 100Mb,tika 文本的最大字节数将为 (writeLimit) 32Mb。
每个 pod 每天解析大约 370,000 个文档。我一直在搞很多不同的设置尝试。
我之前尝试使用实际的 Tika “ForkParser”,但性能远不如生成 tika 服务器。这就是我使用 Tika Server 的原因。
我不讨厌这样的表现结果......但我觉得我最好伸出手来确保没有人在那里理智地检查我的数字并且就像“哇,这太糟糕了表现,你应该像我一样变得xyz!”
有没有人在做类似的事情?如果是这样,您最终选择了哪些设置?
另外,我想知道当我调用我的 Tika Server/rmeta/text
端点时,Apache Http Client 是否会在这里造成任何开销。我正在使用共享连接池。说为每个线程使用唯一的 HttpClients.createDefault() 而不是在线程之间共享连接池有什么好处吗?