ONLYOFFICE DocumentServer转换器工作线程数量限制问题分析

问题背景

在ONLYOFFICE DocumentServer 8.0.0版本中，用户发现文档转换服务(FileConverter)的工作线程数量被固定为1，无法根据系统CPU核心数或配置文件中的maxprocesscount参数进行动态调整。这导致了在高负载情况下文档转换性能显著下降，从平均2秒/次增加到40秒以上。

技术原理分析

文档转换服务是ONLYOFFICE的核心组件之一，负责处理各种文档格式的相互转换。在7.2.x版本中，该服务能够根据系统CPU核心数自动创建工作线程，实现并行处理能力。但在8.0.0版本中，这一机制发生了变化。

通过代码分析发现，工作线程数量计算逻辑被修改为：

workersCount = Math.min(licenseInfo.count, workersCount);

其中licenseInfo.count在社区版(CE)中被硬编码为1。这意味着无论系统有多少CPU核心或如何配置maxprocesscount参数，最终工作线程数量都不会超过1。

解决方案

对于不同部署方式，解决方案有所区别：

1. Kubernetes部署：

   • 官方提供的k8s容器镜像(docs-converter-de)设计原则是"一个容器一个进程"
   • 需要通过增加Pod副本数来实现水平扩展
   • 可使用官方Helm chart中的副本数配置进行调优

2. Docker直接部署：

   • 应使用documentserver-de镜像而非docs-converter-de
   • 该镜像支持多工作线程模式
   • 可通过配置文件调整工作线程数量

3. 自定义构建：

   • 从源码构建镜像时可以修改默认配置
   • 需要调整docker-entrypoint.sh中的相关参数
   • 可设置NODE_CONFIG环境变量覆盖默认值

性能优化建议

对于高负载生产环境，建议：

1. 监控文档转换服务的响应时间
2. 根据负载情况动态调整Pod副本数(k8s)或工作线程数(Docker)
3. 确保Redis、RabbitMQ等依赖服务的资源配置充足
4. 考虑使用企业版(DE)以获得更好的性能特性

版本兼容性说明

这一问题主要影响8.0.0及以上版本。7.2.x版本仍保持原有的动态工作线程创建机制。用户在升级时应注意这一变化，并提前做好性能测试和容量规划。

总结

ONLYOFFICE DocumentServer在不同部署模式下对文档转换工作线程的处理方式有所区别。理解这一机制有助于用户根据实际需求选择最适合的部署方案和性能调优方法。对于k8s环境，应采用水平扩展策略；而对于传统Docker部署，则可通过配置调整垂直扩展能力。