Hårdvarukrav

Hårdvarukrav

När du tillhandahåller hårdvara för att köra Overleaf är den viktigaste faktorn att ta hänsyn till hur många samtidiga användare som kommer att köra kompileringar.

Om du till exempel har en licens för totalt 100 användare men bara förväntar dig att ~5 arbetar samtidigt räcker minimiinstallationen. Om du förväntar dig att en större andel arbetar (och kompilerar) samtidigt bör du överväga att tillhandahålla en server med högre prestanda.

Minimiinstallation

Ett grundläggande minimikrav på 2 kärnor och 3 GB minne krävs för grundläggande drift med omkring 5 samtidiga användare. Detta minimikrav räcker även för större grupper där den samtidiga användningen är lägre, eller där det är acceptabelt med längre kompileringstider vid hög belastning.

Om du överväger att använda ett filsystem baserat på NFS (Network File System) för din lilla instans, läs det här avsnittet under Felsökning.

Skalning

Som tumregel bör 1 CPU-kärna och 1 GB minne läggas till minimiinstallationen för var 5–10 samtidiga användare för att ge en hög och jämn servicenivå.

Detta ska endast ses som en vägledning, eftersom faktorer som storleken på typiska dokument (större dokument förbrukar mer kompileringsresurser), hur ofta användarna kompilerar och hur stor tolerans det finns för längre kompileringstider vid hög belastning alla påverkar hur mycket resurser som krävs.

Många av våra kunder vill driftsätta Server Pro i hela organisationen eller i stora team. I sådana situationer är det svårt för oss att ge råd om specifika krav på uppsättningen, eftersom användningsfallen och den tillgängliga hårdvaran kan variera kraftigt.

Exempel 1	Exempel 2
Om du kör en Server Pro-installation för totalt 300 användare och regelbundet förväntar dig att 30–60 av dem kompilerar dokument samtidigt, bör 8 GB och 7 kärnor (5 kärnor + 5 GB + en bas på 2 kärnor och 3 GB) ge tillräckliga resurser för att användarna ska få en genomgående hög servicenivå.	Som ett exempel på hårdvarukraven för en större driftsättning har en Server Pro-installation för totalt 1 000 användare framgångsrikt satts upp med en enda server utrustad med två processorer med 4 kärnor och 32 GB systemminne. Detta har räckt för teamets behov under det senaste årets användning.

Kunder som överskrider gränserna för en enda stor server kan läsa om horisontell skalning för Server Pro.

Lagring

Vi avråder från att använda Network File System (NFS)/Amazon EFS/Amazon EBS för projekt- och historiklagring i större installationer och stöder det uttryckligen inte vid horisontell skalning.

Dessa filsystem ger inte den prestanda och tillförlitlighet som Server Pro behöver vid drift i stor skala. När filsystemet inte hinner med belastningen stannar applikationen upp på grund av för många blockerande IO-operationer. Sådana avbrott kan leda till att Redis-baserade lås överskrids, vilket i sin tur kan resultera i korrupt projektdata.

Vi rekommenderar i stället att du använder S3-kompatibel objektlagring. Långsam S3-prestanda påverkar endast uppladdning/nedladdning av filer, vilket bara leder till ett ökat antal öppna anslutningar till din S3-leverantör och därmed inte påverkar resten av applikationens beteende. Dessutom kan Server Pro ange rimliga tidsgränser för S3-förfrågningar, vilket inte är möjligt för filsystems-/IO-operationer på applikationsnivå.

Som jämförelse har GitLab en liknande hållning genom att inte stödja NFS/Amazon EFS för sin självförvaltade lösning.

Nginx-specifik konfiguration för stora driftsättningar

Som standard begränsar Overleaf Server-instanser antalet anslutningar till 768. Detta inkluderar beständiga WebSocket-anslutningar, HTML-navigering på toppnivå och ajax-förfrågningar. När gränsen nås kan editorn misslyckas med att ansluta, editorsidan kanske inte laddas helt och kompileringsförfrågningar kan misslyckas. Nginx returnerar då svar med status 500 och loggar worker_connections are not enough while connecting to upstream i var/log/nginx/error.log i containern sharelatex.

Inställningen worker_connections begränsar antalet samtidiga anslutningar som nginx tar emot per worker. Antalet workers styrs av inställningen worker_processes och är satt till 4 som standard i vår nginx-konfiguration.

Nginx utför inte mycket arbete jämfört med andra delar av systemet, så dessa gränser fungerar som ett skydd som förhindrar att för många anslutningar överbelastar systemet. Det är bättre att tidigt avvisa vissa överskottsanslutningar än att göra alla anslutningar långsammare.

Overleaf Server-instanser exponerar miljövariabler för att justera dessa nginx-inställningar:

• 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)

  När en annan proxy körs framför containern sharelatex (t.ex. för TLS-terminering) måste NGINX_KEEPALIVE_TIMEOUT i Overleaf Server-instansen vara större än i den föregående proxyn. Här är två exempel med en annan nginx-process på Docker-värden nginx-host:

• Standardvärde för NGINX_KEEPALIVE_TIMEOUT: använd keepalive_timeout 60s (standardvärde i upstream) i nginx-host

• Eget värde NGINX_KEEPALIVE_TIMEOUT=100s: använd keepalive_timeout 90s (eget värde i upstream) i nginx-host

CPU-hastighet

LaTeX är ett enkeltrådat program, vilket innebär att det bara kan använda en CPU-kärna åt gången. CPU:n är också den huvudsakliga begränsningen vid kompilering av ett dokument. Ju snabbare enkelkärnsprestanda din CPU har, desto snabbare kan du därför kompilera ett dokument. Fler kärnor hjälper bara om du försöker kompilera fler dokument än du har lediga CPU-kärnor.