> For the complete documentation index, see [llms.txt](https://ayakaleaf-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://ayakaleaf-pro.ayaka.space/on-premises/nl/aan-de-slag/requirements/hardware-requirements.md). # Hardwarevereisten ## Hardwarevereisten Bij het provisioneren van hardware om Overleaf uit te voeren, is de belangrijkste factor om rekening mee te houden hoeveel gelijktijdige gebruikers compilaties zullen uitvoeren. Als je bijvoorbeeld een licentie hebt voor 100 totale gebruikers, maar verwacht dat slechts \~5 daarvan tegelijkertijd aan het werk zullen zijn, is de minimale installatie voldoende. Als je verwacht dat een groter deel gelijktijdig aan het werk is (en compileert), kun je overwegen een server met een hogere specificatie te provisioneren. ### Minimale installatie Een minimale basisvereiste van 2 cores en 3 GB geheugen is vereist voor basisbewerkingen met ongeveer 5 gelijktijdige gebruikers. Deze minimumvereiste is ook voldoende voor grotere groepen waar er minder gelijktijdig gebruik is, of waar het acceptabel is dat compiletijden langer zijn tijdens zwaarder gebruik. {% hint style="danger" %} Als je overweegt een op NFS (Network File System) gebaseerd bestandssysteem te gebruiken voor je kleine instantie, bekijk dan deze sectie in de [Probleemoplossing](/on-premises/nl/ondersteuning/troubleshooting.md) sectie. {% endhint %} ### Schalen Als vuistregel geldt dat, om een hoog en consistent serviceniveau te bieden, voor elke 5-10 gelijktijdige gebruikers 1 CPU-core en 1 GB geheugen aan de minimale installatie moet worden toegevoegd. Dit moet alleen als richtlijn worden gezien, aangezien factoren zoals de grootte van typische documenten (grotere documenten gebruiken meer compileresources), hoe vaak gebruikers compileren en hoeveel tolerantie er is voor langere compiletijden tijdens zwaar gebruik, allemaal van invloed zijn op het vereiste provisioneringsniveau. Veel van onze klanten willen Server Pro organisatiebreed of over grote teams heen uitrollen. In die situaties is het voor ons moeilijk om advies te geven over specifieke installatievereisten, omdat de gebruiksscenario's 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 je regelmatig verwacht dat 30-60 van die gebruikers tegelijkertijd documenten zullen compileren, zouden 8 GB en 7 cores (5 cores + 5 GB + basis van 2 cores en 3 GB) voldoende middelen moeten bieden om je gebruikers een consistent hoog serviceniveau te geven. | 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 een enkele server die is voorzien van twee 4-coreprocessors en 32 GB systeemgeheugen. Dit was gedurende het afgelopen jaar gebruik voldoende voor de behoeften van het team. | Klanten die de grenzen van een enkele grote server overschrijden, kunnen een kijkje nemen bij [Horizontaal schalen](/on-premises/nl/onderhoud/horizontal-scaling.md) voor Server Pro. ### Opslag Wij raden af om Network File System (NFS)/Amazon EFS/Amazon EBS te gebruiken voor project-/historieopslag 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 bijbenen, loopt de applicatie vast door te veel blokkerende IO-bewerkingen. Deze vastlopers kunnen ertoe leiden dat Redis-gebaseerde locks te lang blijven staan, wat op zijn beurt kan resulteren in beschadigde projectgegevens. Wij adviseren om in plaats daarvan [S3-compatibele objectopslag](/on-premises/nl/aan-de-slag/what-is-the-overleaf-toolkit.md) te gebruiken. Trage S3-prestaties hebben op hun beurt alleen invloed op het uploaden/downloaden van bestanden, wat alleen leidt tot een groter aantal open verbindingen met je S3-provider en op zijn beurt geen invloed heeft op het gedrag van de rest van de applicatie. Daarnaast kan Server Pro redelijke time-outs specificeren voor S3-verzoeken, wat niet mogelijk is voor bestandssysteem-/IO-bewerkingen op applicatieniveau. {% hint style="info" %} Ter referentie: GitLab hanteert een vergelijkbare positie door [NFS/Amazon EFS niet te ondersteunen](https://docs.gitlab.com/ee/administration/nfs.html) in zijn zelfbeheerde aanbod. {% endhint %} ### Nginx-specifieke configuratie voor grote implementaties Standaard beperken Overleaf Server-instanties het aantal verbindingen tot 768. Dit omvat persistente WebSocket-verbindingen, HTML-navigatie op het hoogste niveau en ajaxverzoeken. Zodra de limiet is bereikt, kan de editor mogelijk geen verbinding maken, de editorpagina wordt mogelijk niet volledig geladen en compileverzoeken kunnen 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 op 4 in onze nginx-configuratie. Nginx doet vergeleken met andere onderdelen van het systeem niet veel werk, dus deze limieten fungeren als beveiliging om te voorkomen dat te veel verbindingen het systeem overweldigen. Het verdient de voorkeur om overtollige verbindingen vroegtijdig te laten vallen in plaats van elke verbinding te vertragen. Overleaf Server-instanties stellen omgevingsvariabelen beschikbaar 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`)

Bij het draaien van een andere proxy vóór de sharelatex container (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, 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 eendradig programma, wat betekent dat het slechts één CPU-core tegelijk kan benutten. De CPU is ook de belangrijkste beperking bij het compileren van een document. Hoe sneller dus de single-coreprestaties van je CPU, hoe sneller je een document kunt compileren. Meer cores helpen alleen als je meer documenten probeert te compileren dan je 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://ayakaleaf-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.