硬件要求
在为运行 Overleaf 配置硬件时，需要考虑的主要因素是会有多少并发用户在运行编译。 例如，如果你拥有 100 个用户的许可证，但预计只有约 5 人同时工作，那么最小安装就足够了。如果你预计有更高比例的用户同时工作（并编译），则应考虑配置更高规格的服务器。最小安装
在约 5 个并发用户的情况下，基本运行至少需要 2 个 CPU 核心和 3GB 内存。对于并发使用较少的大型团队，或者在高负载期间可以接受较长编译时间的情况，这一最低要求同样足够。如果你考虑为小型实例使用基于 NFS（网络文件系统）的文件系统，请查看故障排除部分中的相关内容。
扩展
根据经验，为了提供高水平且稳定的服务，每增加 5-10 个并发用户，应在最小安装的基础上增加 1 个 CPU 核心和 1GB 内存。 这仅应作为参考，因为典型文档的大小（较大的文档会占用更多编译资源）、用户编译的频率，以及在高负载期间对较长编译时间的容忍程度等因素，都会影响所需的资源配置水平。 我们的许多客户希望在整个组织或大型团队中部署 Server Pro。在这些情况下，我们很难给出具体的配置建议，因为使用场景和可用的底层硬件可能差异很大。
超出单台大型服务器承载能力的客户，可以参阅 Server Pro 的水平扩展。
存储
在较大规模的部署中，我们不建议将网络文件系统（NFS）/Amazon EFS/Amazon EBS 用于项目/历史记录存储，并且在水平扩展场景中明确不支持这些文件系统。 这些文件系统的表现无法提供 Server Pro 在大规模运行时所需的性能和可靠性。当文件系统无法跟上负载时，应用会因过多的阻塞式 IO 操作而停滞。这些停滞可能导致基于 Redis 的锁超时，进而可能造成项目数据损坏。 我们建议改用 S3 兼容的对象存储。S3 性能较慢只会影响文件的上传/下载，最多导致与 S3 提供商之间的打开连接数增加，而不会影响应用其余部分的行为。此外，Server Pro 可以为 S3 请求设置合理的超时时间，而在应用层面无法对文件系统/IO 操作做到这一点。作为参考，GitLab 在其自托管产品中也采取了类似立场，不支持 NFS/Amazon EFS。
大型部署的 Nginx 专项配置
默认情况下，Overleaf Server 实例将连接数限制为 768。这包括持久的 Websocket 连接、顶层 HTML 导航以及 ajax 请求。一旦达到上限，编辑器可能无法连接，编辑器页面可能无法完全加载，编译请求也可能失败。Nginx 将返回状态码 500 的响应，并在sharelatex 容器内的 var/log/nginx/error.log 中记录 worker_connections are not enough while connecting to upstream。
worker_connections 设置限制了 nginx 每个 worker 可接受的并发连接数。worker 的数量由 worker_processes 设置控制，在我们的 nginx 配置中默认为 4。
与系统的其他部分相比，Nginx 的工作量并不大，因此这些限制起到安全保护作用，防止过多连接压垮系统。尽早丢弃一些多余的连接，要好过拖慢所有连接。
Overleaf Server 实例提供了用于调整这些 nginx 设置的环境变量：
-
NGINX_WORKER_PROCESSES对应worker_processes（默认4） -
NGINX_WORKER_CONNECTIONS对应worker_connections（默认768） -
NGINX_KEEPALIVE_TIMEOUT对应keepalive_timeout（默认65）当在sharelatex容器前运行另一个代理（例如用于 TLS 终止）时，Overleaf Server 实例中的NGINX_KEEPALIVE_TIMEOUT需要大于前一个代理的值。例如，在 Docker 主机 nginx-host 上运行另一个 nginx 进程时，有以下两个示例： -
使用默认值
NGINX_KEEPALIVE_TIMEOUT时，在 nginx-host 中使用keepalive_timeout 60s（upstream 中的默认值） -
使用自定义值
NGINX_KEEPALIVE_TIMEOUT=100s时，在 nginx-host 中使用keepalive_timeout 90s（upstream 中的自定义值）