Hardwarekrav

Hardwarekrav

Når du skal klargøre hardware til at køre Overleaf, er den vigtigste faktor at tage højde for, hvor mange samtidige brugere der vil køre kompileringer.

Hvis du for eksempel har en licens til 100 brugere i alt, men kun forventer, at ~5 arbejder samtidig, vil den minimale installation være tilstrækkelig. Hvis du forventer, at en større andel arbejder (og kompilerer) samtidig, bør du overveje at klargøre en server med en højere specifikation.

Minimal installation

Et grundlæggende minimumskrav på 2 kerner og 3 GB hukommelse er nødvendigt for basal drift med omkring 5 samtidige brugere. Dette minimumskrav vil også være tilstrækkeligt for større grupper med mindre samtidig brug, eller hvor det er acceptabelt, at kompileringstiderne er længere under kraftigere belastning.

Hvis du overvejer at bruge et filsystem baseret på NFS (Network File System) til din lille instans, så se venligst dette afsnit under Fejlfinding.

Skalering

Som tommelfingerregel bør der, for at give et højt og stabilt serviceniveau, tilføjes 1 CPU-kerne og 1 GB hukommelse til den minimale installation for hver 5-10 samtidige brugere.

Dette bør kun ses som en vejledning, da faktorer som størrelsen på typiske dokumenter (større dokumenter bruger flere kompileringsressourcer), hvor ofte brugerne kompilerer, og hvilken tolerance der er for længere kompileringstider under kraftig belastning, alle påvirker det nødvendige ressourceniveau.

Mange af vores kunder ønsker at udrulle Server Pro i hele organisationen eller på tværs af store teams. I sådanne situationer er det svært for os at rådgive om specifikke opsætningskrav, fordi anvendelsesscenarierne og den tilgængelige underliggende hardware kan variere meget.

Eksempel 1	Eksempel 2
Hvis du kører en Server Pro-installation for 300 brugere i alt og regelmæssigt forventer, at 30-60 af disse brugere kompilerer dokumenter samtidig, bør 8 GB og 7 kerner (5 kerner + 5 GB + et grundlag på 2 kerner og 3 GB) give tilstrækkelige ressourcer til, at dine brugere får et stabilt højt serviceniveau.	Som et eksempel på hardwarekravene til en større udrulning er en Server Pro-installation for 1.000 brugere i alt blevet opsat med succes på en enkelt server udstyret med to 4-kerneprocessorer og 32 GB systemhukommelse. Det har været tilstrækkeligt til teamets behov i løbet af det seneste års brug.

Kunder, der overskrider grænserne for en enkelt stor server, kan se på Horisontal skalering for Server Pro.

Lagring

Vi fraråder at bruge Network File System (NFS)/Amazon EFS/Amazon EBS til projekt- og historiklagring i større opsætninger, og vi understøtter det udtrykkeligt ikke ved horisontal skalering.

Disse filsystemers adfærd giver ikke den nødvendige ydeevne og pålidelighed, som Server Pro har brug for ved drift i stor skala. Når filsystemet ikke kan følge med belastningen, går applikationen i stå på grund af for mange blokerende IO-operationer. Disse stop kan føre til, at Redis-baserede låse udløber, hvilket igen kan resultere i beskadigede projektdata.

Vi anbefaler i stedet at bruge S3-kompatibel objektlagring. Langsom S3-ydeevne påvirker til gengæld kun upload/download af filer, hvilket blot fører til et øget antal åbne forbindelser til din S3-udbyder og ikke påvirker resten af applikationens adfærd. Derudover kan Server Pro angive rimelige timeouts for S3-forespørgsler, hvilket ikke er muligt for filsystem-/IO-operationer på applikationsniveau.

Til sammenligning har GitLab en lignende holdning og understøtter ikke NFS/Amazon EFS i sit selvadministrerede produkt.

Nginx-specifik konfiguration til store udrulninger

Som standard begrænser Overleaf Server-instanser antallet af forbindelser til 768. Dette omfatter vedvarende Websocket-forbindelser, HTML-navigation på øverste niveau og ajax-forespørgsler. Når grænsen nås, kan editoren muligvis ikke oprette forbindelse, editorsiden indlæses måske ikke helt, og kompileringsforespørgsler kan mislykkes. Nginx returnerer svar med status 500 og logger worker_connections are not enough while connecting to upstream i var/log/nginx/error.log inde i sharelatex-containeren.

Indstillingen worker_connections begrænser antallet af samtidige forbindelser, som nginx accepterer pr. worker. Antallet af workers styres af indstillingen worker_processes og er som standard sat til 4 i vores nginx-konfiguration.

Nginx udfører ikke meget arbejde sammenlignet med andre dele af systemet, så disse grænser fungerer som en sikkerhedsforanstaltning, der forhindrer for mange forbindelser i at overbelaste systemet. Det er at foretrække at afvise nogle overskydende forbindelser tidligt frem for at gøre alle forbindelser langsommere.

Overleaf Server-instanser stiller miljøvariabler til rådighed for justering af disse nginx-indstillinger:

• NGINX_WORKER_PROCESSES for worker_processes (standard 4)

• NGINX_WORKER_CONNECTIONS for worker_connections (standard 768)

• NGINX_KEEPALIVE_TIMEOUT for keepalive_timeout (standard 65)

  Når der kører en anden proxy foran sharelatex-containeren (f.eks. til TLS-terminering), skal NGINX_KEEPALIVE_TIMEOUT i Overleaf Server-instansen være større end i den foregående proxy. F.eks. med en anden nginx-proces på Docker-værten nginx-host er her to eksempler:

• Standardværdien for NGINX_KEEPALIVE_TIMEOUT: brug keepalive_timeout 60s (standardværdi i upstream) i nginx-host

• Brugerdefineret værdi NGINX_KEEPALIVE_TIMEOUT=100s: brug keepalive_timeout 90s (brugerdefineret værdi i upstream) i nginx-host

CPU-hastighed

LaTeX er et enkelttrådet program, hvilket betyder, at det kun kan udnytte én CPU-kerne ad gangen. CPU’en er også den primære begrænsning ved kompilering af et dokument. Jo hurtigere enkeltkerneydeevne din CPU har, desto hurtigere kan du derfor kompilere et dokument. Flere kerner hjælper kun, hvis du forsøger at kompilere flere dokumenter, end du har ledige CPU-kerner.