Maskinvarekrav

Maskinvarekrav

Når du klargjør maskinvare for å kjøre Overleaf, er den viktigste faktoren å ta hensyn til hvor mange samtidige brukere som vil kjøre kompileringer.

Hvis du for eksempel har en lisens for totalt 100 brukere, men bare forventer at ~5 jobber samtidig, vil minimumsinstallasjonen være tilstrekkelig. Hvis du forventer at en større andel jobber (og kompilerer) samtidig, bør du vurdere å klargjøre en server med høyere spesifikasjoner.

Minimumsinstallasjon

Et grunnleggende minimum på 2 kjerner og 3 GB minne kreves for grunnleggende drift med rundt 5 samtidige brukere. Dette minimumskravet vil også være tilstrekkelig for større grupper med mindre samtidig bruk, eller der det er greit at kompileringstidene blir lengre under tyngre belastning.

Hvis du vurderer å bruke et filsystem basert på NFS (Network File System) for den lille instansen din, bør du se på denne delen i Feilsøking.

Skalering

Som en tommelfingerregel bør du, for å gi et høyt og stabilt tjenestenivå, legge til 1 CPU-kjerne og 1 GB minne i minimumsinstallasjonen for hver 5–10 samtidige brukere.

Dette bør bare betraktes som en veiledning, siden faktorer som størrelsen på typiske dokumenter (større dokumenter bruker mer kompileringsressurser), hvor ofte brukerne kompilerer og hvor stor toleranse det er for lengre kompileringstider under tung belastning, alle påvirker hvor mye ressurser som kreves.

Mange av kundene våre ønsker å ta i bruk Server Pro i hele organisasjonen eller på tvers av store team. I slike situasjoner er det vanskelig for oss å gi råd om spesifikke oppsettkrav, fordi bruksområdene og den tilgjengelige maskinvaren kan variere mye.

Eksempel 1	Eksempel 2
Hvis du kjører en Server Pro-installasjon for totalt 300 brukere og jevnlig forventer at 30–60 av dem kompilerer dokumenter samtidig, bør 8 GB og 7 kjerner (5 kjerner + 5 GB + et grunnlag på 2 kjerner og 3 GB) gi tilstrekkelige ressurser til at brukerne får et jevnt høyt tjenestenivå.	Som et eksempel på maskinvarekravene for en større distribusjon har en Server Pro-installasjon for totalt 1 000 brukere blitt satt opp med hell på én enkelt server utstyrt med to 4-kjerners prosessorer og 32 GB systemminne. Dette har vært tilstrekkelig for teamets behov gjennom det siste året med bruk.

Kunder som overskrider grensene for én stor server, kan se på Horisontal skalering for Server Pro.

Lagring

Vi fraråder bruk av Network File System (NFS)/Amazon EFS/Amazon EBS til lagring av prosjekter/historikk i større oppsett, og vi støtter det uttrykkelig ikke for horisontal skalering.

Disse filsystemene gir ikke den ytelsen og påliteligheten som Server Pro trenger når den kjører i stor skala. Når filsystemet ikke klarer å holde tritt med belastningen, stopper applikasjonen opp på grunn av for mange blokkerende IO-operasjoner. Slike stopp kan føre til at Redis-baserte låser går ut på tid, noe som igjen kan føre til korrupte prosjektdata.

Vi anbefaler i stedet å bruke S3-kompatibel objektlagring. Treg S3-ytelse påvirker bare opplasting/nedlasting av filer, noe som bare fører til et økt antall åpne tilkoblinger til S3-leverandøren din og ikke påvirker oppførselen til resten av applikasjonen. I tillegg kan Server Pro angi rimelige tidsavbrudd for S3-forespørsler, noe som ikke er mulig for filsystem-/IO-operasjoner på applikasjonsnivå.

Til sammenligning har GitLab en lignende holdning om ikke å støtte NFS/Amazon EFS i sitt selvadministrerte tilbud.

Nginx-spesifikk konfigurasjon for store distribusjoner

Som standard begrenser Overleaf Server-instanser antall tilkoblinger til 768. Dette omfatter vedvarende WebSocket-tilkoblinger, HTML-navigasjon på toppnivå og Ajax-forespørsler. Når grensen er nådd, kan det hende at editoren ikke klarer å koble til, at editorsiden ikke lastes helt inn og at kompileringsforespørsler mislykkes. Nginx vil returnere svar med status 500 og logge worker_connections are not enough while connecting to upstream til var/log/nginx/error.log inne i sharelatex-containeren.

Innstillingen worker_connections begrenser antall samtidige tilkoblinger nginx godtar per worker. Antall workers styres av innstillingen worker_processes og er satt til 4 som standard i vår nginx-konfigurasjon.

Nginx gjør lite arbeid sammenlignet med andre deler av systemet, så disse grensene fungerer som en sikring som hindrer at for mange tilkoblinger overbelaster systemet. Det er bedre å avvise noen overskytende tilkoblinger tidlig enn å gjøre alle tilkoblinger tregere.

Overleaf Server-instanser eksponerer miljøvariabler for å justere disse nginx-innstillingene:

• 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 en annen proxy kjører foran sharelatex-containeren (f.eks. for TLS-terminering), må NGINX_KEEPALIVE_TIMEOUT i Overleaf Server-instansen være større enn i den foregående proxyen. Med for eksempel en annen nginx-prosess på Docker-verten nginx-host er her to eksempler:

• Standardverdi for NGINX_KEEPALIVE_TIMEOUT: bruk keepalive_timeout 60s (standardverdi i upstream) i nginx-host

• Egendefinert verdi NGINX_KEEPALIVE_TIMEOUT=100s: bruk keepalive_timeout 90s (egendefinert verdi i upstream) i nginx-host

CPU-hastighet

LaTeX er et enkelttrådet program, noe som betyr at det bare kan bruke én CPU-kjerne om gangen. CPU-en er også den viktigste begrensningen når et dokument kompileres. Jo raskere enkeltkjerneytelsen til CPU-en din er, desto raskere kan du derfor kompilere et dokument. Flere kjerner hjelper bare hvis du prøver å kompilere flere dokumenter enn du har ledige CPU-kjerner.