> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/on-premises/nl/aan-de-slag/requirements/hardware-requirements.md). # Hardwarevereisten ## Hardwarevereisten Wanneer u hardware inricht om Overleaf uit te voeren, is de belangrijkste factor om rekening mee te houden hoeveel gelijktijdige gebruikers compilaties zullen uitvoeren. Als u bijvoorbeeld een licentie hebt voor in totaal 100 gebruikers, maar verwacht dat er slechts ongeveer 5 tegelijk werken, dan is de minimale installatie voldoende. Als u verwacht dat een groter deel tegelijkertijd werkt (en compileert), moet u overwegen een server met een hogere specificatie in te richten. ### Minimale installatie Een minimale basisvereiste van 2 cores en 3 GB geheugen is nodig voor basisbewerkingen met ongeveer 5 gelijktijdige gebruikers. Deze minimale vereiste is ook voldoende voor grotere groepen waarbij minder gelijktijdig gebruik is, of waarbij het acceptabel is dat compileertijden langer zijn tijdens intensiever gebruik. {% hint style="danger" %} Als u overweegt een op NFS (Network File System) gebaseerd bestandssysteem te gebruiken voor uw kleine instantie, bekijk dan dit onderdeel in de [Probleemoplossing](/on-premises/nl/ondersteuning/troubleshooting.md) sectie. {% endhint %} ### Opschalen Als vuistregel geldt dat, om een hoog en consistent serviceniveau te bieden, voor elke 5-10 gelijktijdige gebruikers 1 CPU-kern en 1 GB geheugen aan de minimale installatie moeten worden toegevoegd. Dit moet alleen als richtlijn worden gezien, aangezien factoren zoals de grootte van typische documenten (grotere documenten gebruiken meer compileerresources), hoe vaak gebruikers compileren en hoeveel tolerantie er is voor langere compileertijden tijdens intensief gebruik, allemaal van invloed zijn op het vereiste niveau van provisioning. Veel van onze klanten willen Server Pro organisatiebreed of voor grote teams uitrollen. In die situaties is het voor ons moeilijk om advies te geven over specifieke configuratievereisten, omdat de gebruikssituaties en de onderliggende beschikbare hardware sterk kunnen verschillen. | Voorbeeld 1 | Voorbeeld 2 | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Als u een Server Pro-installatie draait voor in totaal 300 gebruikers, en u regelmatig verwacht dat 30-60 van die gebruikers tegelijkertijd documenten aan het compileren zijn, zouden 8 GB en 7 cores (5 cores + 5 GB + basis van 2 cores & 3 GB) voldoende middelen moeten bieden zodat uw gebruikers een consistent hoog serviceniveau hebben. | Om een voorbeeld te geven van de hardwarevereisten voor een grotere uitrol: een Server Pro-installatie voor in totaal 1.000 gebruikers is succesvol opgezet met één server voorzien van twee processors met 4 cores en 32 GB systeemgeheugen. Dit was het afgelopen jaar van gebruik voldoende voor de behoeften van het team. | Klanten die de grenzen van één grote server overschrijden, kunnen eens kijken naar [Horizontaal schalen](/on-premises/nl/onderhoud/horizontal-scaling.md) voor Server Pro. ### Opslag We raden af om Network File System (NFS)/Amazon EFS/Amazon EBS te gebruiken voor opslag van projecten/historie in grotere opstellingen en ondersteunen dit expliciet **niet** voor horizontaal schalen. Het gedrag van deze bestandssystemen biedt niet de noodzakelijke prestaties en betrouwbaarheid die Server Pro nodig heeft bij gebruik op grote schaal. Wanneer het bestandssysteem de belasting niet kan bijhouden, loopt de applicatie vast door te veel blokkerende I/O-bewerkingen. Deze vastlopers kunnen ertoe leiden dat op Redis gebaseerde locks verlopen, wat op zijn beurt kan resulteren in beschadigde projectgegevens. We adviseren om [S3-compatibele objectopslag](/on-premises/nl/aan-de-slag/what-is-the-overleaf-toolkit.md) te gebruiken. Trage S3-prestaties beïnvloeden op hun beurt alleen het uploaden/downloaden van bestanden, wat alleen leidt tot een groter aantal open verbindingen met uw S3-provider en op zijn beurt het gedrag van de rest van de applicatie niet beïnvloedt. Daarnaast kan Server Pro redelijke time-outs specificeren voor S3-verzoeken, wat niet mogelijk is voor bestandssysteem-/I/O-bewerkingen op applicatieniveau. {% hint style="info" %} Ter referentie: GitLab hanteert een vergelijkbaar standpunt van [geen ondersteuning voor NFS/Amazon EFS](https://docs.gitlab.com/ee/administration/nfs.html) met hun zelfbeheerde aanbod. {% endhint %} ### Nginx-specifieke configuratie voor grote implementaties Standaard beperken Overleaf Server-instanties het aantal verbindingen tot 768. Hieronder vallen persistente WebSocket-verbindingen, top-level HTML-navigatie en ajax-verzoeken. Zodra de limiet is bereikt, kan de editor mogelijk geen verbinding maken, kan de editorpagina mogelijk niet volledig laden en kunnen compileerverzoeken mislukken. Nginx geeft dan status 500-responses terug en logt `worker_connections zijn niet voldoende tijdens het verbinden met upstream` naar `var/log/nginx/error`.log in de `sharelatex` container. De [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) instelling beperkt het aantal gelijktijdige verbindingen dat nginx per worker accepteert. Het aantal workers wordt geregeld door de [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) instelling en staat standaard ingesteld op 4 in onze nginx-configuratie. Nginx doet vergeleken met andere onderdelen van het systeem niet veel werk, dus deze limieten fungeren als een beveiliging die voorkomt dat te veel verbindingen het systeem overweldigen. Het heeft de voorkeur om een deel van de overtollige verbindingen vroegtijdig af te wijzen in plaats van elke verbinding te vertragen. Overleaf Server-instanties bieden omgevingsvariabelen aan voor het aanpassen van deze nginx-instellingen: * `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 er 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 vorige proxy. Bijvoorbeeld, met een ander nginx-proces op de Docker-host nginx-host, hier zijn 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 op een gegeven moment slechts één CPU-kern kan gebruiken. De CPU is ook de belangrijkste beperking bij het compileren van een document. Hoe sneller dus de single-coreprestaties van uw CPU zijn, hoe sneller u een document kunt compileren. Meer cores helpen alleen als u meer documenten probeert te compileren dan u vrije CPU-cores hebt. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://overleaf-pro.ayaka.space/on-premises/nl/aan-de-slag/requirements/hardware-requirements.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.