Skip to main content

​
Hardwareanforderungen

Bei der Bereitstellung von Hardware für Overleaf ist der wichtigste Faktor, wie viele Benutzer gleichzeitig Kompilierungen ausführen werden. Wenn Sie beispielsweise eine Lizenz für insgesamt 100 Benutzer haben, aber nur mit ~5 gleichzeitig arbeitenden Benutzern rechnen, reicht die Minimalinstallation aus. Wenn Sie erwarten, dass ein größerer Anteil gleichzeitig arbeitet (und kompiliert), sollten Sie einen Server mit höherer Ausstattung in Betracht ziehen.

​
Minimalinstallation

Für den Grundbetrieb mit etwa 5 gleichzeitigen Benutzern sind mindestens 2 Kerne und 3 GB Arbeitsspeicher erforderlich. Diese Mindestanforderung reicht auch für größere Gruppen mit geringerer gleichzeitiger Nutzung aus oder wenn längere Kompilierzeiten bei hoher Auslastung akzeptabel sind.
Wenn Sie erwägen, für Ihre kleine Instanz ein NFS-basiertes Dateisystem (Network File System) zu verwenden, lesen Sie bitte diesen Abschnitt im Bereich Fehlerbehebung.

​
Skalierung

Als Faustregel gilt: Um ein hohes und gleichbleibendes Serviceniveau zu bieten, sollten zur Minimalinstallation pro 5–10 gleichzeitige Benutzer 1 CPU-Kern und 1 GB Arbeitsspeicher hinzugefügt werden. Dies ist nur als Richtwert zu verstehen, da Faktoren wie die Größe typischer Dokumente (größere Dokumente verbrauchen mehr Kompilierressourcen), die Häufigkeit des Kompilierens und die Toleranz gegenüber längeren Kompilierzeiten bei hoher Auslastung den erforderlichen Ressourcenbedarf beeinflussen. Viele unserer Kunden möchten Server Pro organisationsweit oder in großen Teams einsetzen. In solchen Fällen ist es für uns schwierig, konkrete Empfehlungen zur Einrichtung zu geben, da die Anwendungsfälle und die verfügbare Hardware sehr unterschiedlich sein können. Kunden, die an die Grenzen eines einzelnen großen Servers stoßen, können sich die horizontale Skalierung für Server Pro ansehen.

​
Speicher

Wir raten davon ab, Network File System (NFS)/Amazon EFS/Amazon EBS in größeren Installationen als Projekt-/Verlaufsspeicher zu verwenden, und unterstützen dies ausdrücklich nicht für die horizontale Skalierung. Diese Dateisysteme bieten nicht die Leistung und Zuverlässigkeit, die Server Pro im Betrieb mit hoher Last benötigt. Wenn das Dateisystem mit der Last nicht Schritt halten kann, gerät die Anwendung durch zu viele blockierende IO-Operationen ins Stocken. Solche Stockungen können dazu führen, dass Redis-basierte Sperren überschritten werden, was wiederum beschädigte Projektdaten zur Folge haben kann. Wir empfehlen stattdessen die Verwendung von S3-kompatiblem Objektspeicher. Eine langsame S3-Leistung wirkt sich nur auf das Hoch- und Herunterladen von Dateien aus, was lediglich zu einer erhöhten Anzahl offener Verbindungen zu Ihrem S3-Anbieter führt und das Verhalten der übrigen Anwendung nicht beeinträchtigt. Zudem kann Server Pro für S3-Anfragen sinnvolle Timeouts festlegen, was für Dateisystem-/IO-Operationen auf Anwendungsebene nicht möglich ist.
Zum Vergleich: GitLab vertritt bei seinem selbstverwalteten Angebot eine ähnliche Haltung und unterstützt NFS/Amazon EFS nicht.

​
Nginx-spezifische Konfiguration für große Bereitstellungen

Standardmäßig begrenzt eine Overleaf Server-Instanz die Anzahl der Verbindungen auf 768. Dazu zählen dauerhafte Websocket-Verbindungen, HTML-Navigationen auf oberster Ebene und Ajax-Anfragen. Sobald das Limit erreicht ist, kann der Editor möglicherweise keine Verbindung herstellen, die Editorseite wird eventuell nicht vollständig geladen und Kompilierungsanfragen können fehlschlagen. Nginx gibt dann Antworten mit Status 500 zurück und protokolliert worker_connections are not enough while connecting to upstream in var/log/nginx/error.log im sharelatex-Container. Die Einstellung worker_connections begrenzt die Anzahl gleichzeitiger Verbindungen, die nginx pro Worker annimmt. Die Anzahl der Worker wird über die Einstellung worker_processes gesteuert und ist in unserer nginx-Konfiguration standardmäßig auf 4 gesetzt. Nginx leistet im Vergleich zu anderen Teilen des Systems nur wenig Arbeit, daher dienen diese Limits als Schutz davor, dass zu viele Verbindungen das System überlasten. Es ist besser, einige überzählige Verbindungen frühzeitig abzuweisen, als jede Verbindung zu verlangsamen. Overleaf Server-Instanzen stellen Umgebungsvariablen zur Anpassung dieser nginx-Einstellungen bereit:
  • NGINX_WORKER_PROCESSES für worker_processes (Standard 4)
  • NGINX_WORKER_CONNECTIONS für worker_connections (Standard 768)
  • NGINX_KEEPALIVE_TIMEOUT für keepalive_timeout (Standard 65)
    Wenn Sie einen weiteren Proxy vor dem sharelatex-Container betreiben (z. B. für die TLS-Terminierung), muss NGINX_KEEPALIVE_TIMEOUT in der Overleaf Server-Instanz größer sein als beim vorgelagerten Proxy. Hier zwei Beispiele mit einem weiteren nginx-Prozess auf dem Docker-Host nginx-host:
  • Standardwert für NGINX_KEEPALIVE_TIMEOUT: Verwenden Sie keepalive_timeout 60s (Standardwert im Upstream) in nginx-host
  • Benutzerdefinierter Wert NGINX_KEEPALIVE_TIMEOUT=100s: Verwenden Sie keepalive_timeout 90s (benutzerdefinierter Wert im Upstream) in nginx-host

​
CPU-Geschwindigkeit

LaTeX ist ein Single-Thread-Programm, das heißt, es kann jeweils nur einen CPU-Kern nutzen. Die CPU ist zudem der wichtigste begrenzende Faktor beim Kompilieren eines Dokuments. Je höher also die Single-Core-Leistung Ihrer CPU ist, desto schneller können Sie ein Dokument kompilieren. Mehr Kerne helfen nur, wenn Sie mehr Dokumente gleichzeitig kompilieren möchten, als Sie freie CPU-Kerne haben.
Last modified on October 4, 2026