> ## Documentation Index > Fetch the complete documentation index at: https://ayakaleaf-pro.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Hardwarevereisten ## Hardwarevereisten Bij het inrichten van hardware voor Overleaf is de belangrijkste factor hoeveel gelijktijdige gebruikers compilaties zullen uitvoeren. Als je bijvoorbeeld een licentie hebt voor in totaal 100 gebruikers, maar verwacht dat er slechts \~5 tegelijk actief zijn, volstaat de minimale installatie. Als je verwacht dat een groter deel tegelijk werkt (en compileert), overweeg dan een server met hogere specificaties. ### Minimale installatie Voor basisgebruik met ongeveer 5 gelijktijdige gebruikers is minimaal 2 cores en 3 GB geheugen vereist. Deze minimumvereiste volstaat ook voor grotere groepen waarin minder gelijktijdig gebruik plaatsvindt, of waarin langere compileertijden tijdens drukke momenten acceptabel zijn. Als je overweegt een bestandssysteem op basis van NFS (Network File System) te gebruiken voor je kleine instantie, bekijk dan dit onderdeel in de sectie [Probleemoplossing](/nl/on-premises/support/troubleshooting). ### Schalen Als vuistregel geldt dat je, voor een hoog en consistent serviceniveau, voor elke 5-10 gelijktijdige gebruikers 1 CPU-core en 1 GB geheugen aan de minimale installatie moet toevoegen. Zie dit slechts als richtlijn: factoren zoals de grootte van typische documenten (grotere documenten verbruiken meer compileerresources), hoe vaak gebruikers compileren en hoeveel tolerantie er is voor langere compileertijden bij intensief gebruik, hebben allemaal invloed op de benodigde capaciteit. Veel van onze klanten willen Server Pro organisatiebreed of voor grote teams uitrollen. In die situaties is het lastig voor ons om specifieke installatievereisten te adviseren, omdat de use cases en de beschikbare onderliggende hardware sterk kunnen verschillen. | Voorbeeld 1 | Voorbeeld 2 | | - | - | | Als je een Server Pro-installatie draait voor in totaal 300 gebruikers en regelmatig verwacht dat 30-60 van hen tegelijk documenten compileren, dan zou 8 GB en 7 cores (5 cores + 5 GB + basis van 2 cores en 3 GB) voldoende resources moeten bieden om je gebruikers een consistent hoog serviceniveau te geven. | Als voorbeeld van de hardwarevereisten voor een grotere deployment: een Server Pro-installatie voor in totaal 1.000 gebruikers is met succes opgezet op één server met twee 4-coreprocessors en 32 GB systeemgeheugen. Dit voldeed het afgelopen gebruiksjaar ruimschoots aan de behoeften van het team. | Klanten die de grenzen van één grote server overschrijden, kunnen kijken naar [Horizontaal schalen](/nl/on-premises/maintenance/horizontal-scaling) voor Server Pro. ### Opslag We raden het gebruik van Network File System (NFS)/Amazon EFS/Amazon EBS voor project-/geschiedenisopslag in grotere opstellingen af en ondersteunen dit uitdrukkelijk **niet** bij horizontaal schalen. Deze bestandssystemen leveren niet de prestaties en betrouwbaarheid die Server Pro op grote schaal nodig heeft. Wanneer het bestandssysteem de belasting niet kan bijbenen, loopt de applicatie vast door te veel blokkerende IO-operaties. Deze vertragingen kunnen ertoe leiden dat op Redis gebaseerde locks verlopen, wat op zijn beurt kan resulteren in beschadigde projectgegevens. We raden in plaats daarvan aan [S3-compatibele objectopslag](/nl/on-premises/getting-started/what-is-the-overleaf-toolkit) te gebruiken. Trage S3-prestaties hebben alleen invloed op het uploaden/downloaden van bestanden, wat slechts leidt tot een verhoogd aantal open verbindingen met je S3-provider en verder geen invloed heeft op het gedrag van de rest van de applicatie. Bovendien kan Server Pro redelijke time-outs instellen voor S3-verzoeken, wat op applicatieniveau niet mogelijk is voor bestandssysteem-/IO-operaties. Ter referentie: GitLab hanteert een vergelijkbaar standpunt door [NFS/Amazon EFS niet te ondersteunen](https://docs.gitlab.com/ee/administration/nfs.html) in zijn self-managed aanbod. ### Nginx-specifieke configuratie voor grote deployments Standaard beperken Overleaf Server-instanties het aantal verbindingen tot 768. Dit omvat persistente Websocket-verbindingen, HTML-navigatie op topniveau en ajax-verzoeken. Zodra de limiet is bereikt, kan de editor mogelijk geen verbinding maken, wordt de editorpagina mogelijk niet volledig geladen en kunnen compileerverzoeken mislukken. Nginx retourneert dan responses met status 500 en logt `worker_connections are not enough while connecting to upstream` in `var/log/nginx/error`.log binnen de `sharelatex`-container. De instelling [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) beperkt het aantal gelijktijdige verbindingen dat nginx per worker accepteert. Het aantal workers wordt bepaald door de instelling [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) en staat in onze nginx-configuratie standaard op 4. Nginx doet relatief weinig werk vergeleken met andere delen van het systeem, dus deze limieten fungeren als een veiligheidsmaatregel die voorkomt dat te veel verbindingen het systeem overbelasten. Het is beter om enkele overtollige verbindingen vroegtijdig te laten vallen dan elke verbinding te vertragen. Overleaf Server-instanties bieden omgevingsvariabelen om deze nginx-instellingen aan te passen: * `NGINX_WORKER_PROCESSES` voor [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) (standaard `4`) * `NGINX_WORKER_CONNECTIONS` voor [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) (standaard `768`) * `NGINX_KEEPALIVE_TIMEOUT` voor [`keepalive_timeout`](https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout) (standaard `65`) Wanneer je een andere proxy vóór de `sharelatex`-container draait (bijv. voor TLS-terminatie), moet de `NGINX_KEEPALIVE_TIMEOUT` in de Overleaf Server-instantie groter zijn dan die van de voorgaande proxy. Bijvoorbeeld met een ander nginx-proces op de Docker-host nginx-host zijn hier twee voorbeelden: * Standaardwaarde `NGINX_KEEPALIVE_TIMEOUT`: gebruik [`keepalive_timeout 60s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (standaardwaarde in upstream) in **nginx-host** * Aangepaste waarde `NGINX_KEEPALIVE_TIMEOUT=100s`: gebruik [`keepalive_timeout 90s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (aangepaste waarde in upstream) in **nginx-host** ### CPU-snelheid LaTeX is een single-threaded programma, wat betekent dat het slechts één CPU-core tegelijk kan gebruiken. De CPU is ook de belangrijkste beperkende factor bij het compileren van een document. Hoe beter de single-coreprestaties van je CPU, hoe sneller je een document kunt compileren. Meer cores helpen alleen als je meer documenten tegelijk probeert te compileren dan je vrije CPU-cores hebt. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.