> 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/fr/demarrage/requirements/hardware-requirements.md). # Exigences matérielles ## Exigences matérielles Lors de la mise à disposition du matériel pour exécuter Overleaf, le principal facteur à prendre en compte est le nombre d’utilisateurs simultanés qui lanceront des compilations. Par exemple, si vous disposez d’une licence pour 100 utilisateurs au total, mais que vous pensez qu’environ 5 seulement travailleront en même temps, l’installation minimale suffira. Si vous pensez qu’une proportion plus importante travaillera (et compilera) simultanément, vous devriez envisager de provisionner un serveur avec des spécifications plus élevées. ### Installation minimale Une exigence minimale de base de 2 cœurs et 3 Go de mémoire est nécessaire pour les opérations de base avec environ 5 utilisateurs simultanés. Cette exigence minimale conviendra également à des groupes plus importants où l’utilisation simultanée est moindre, ou lorsque des temps de compilation plus longs sont acceptables lors des périodes d’utilisation intensive. {% hint style="danger" %} Si vous envisagez d’utiliser un système de fichiers basé sur NFS (Network File System) pour votre petite instance, veuillez consulter cette section dans le [Dépannage](/on-premises/fr/assistance/troubleshooting.md) section. {% endhint %} ### Mise à l’échelle En règle générale, pour offrir un niveau de service élevé et constant, il convient d’ajouter 1 cœur CPU et 1 Go de mémoire à l’installation minimale pour chaque groupe de 5 à 10 utilisateurs simultanés. Cela ne doit être considéré que comme un guide, car des facteurs tels que la taille des documents habituels (les documents plus volumineux consomment davantage de ressources de compilation), la fréquence à laquelle les utilisateurs compilent, et la tolérance aux temps de compilation plus longs lors des périodes d’utilisation intensive, influencent tous le niveau de provisionnement requis. Beaucoup de nos clients cherchent à déployer Server Pro à l’échelle de toute l’organisation, ou au sein de grandes équipes. Dans ces situations, il nous est difficile de conseiller des exigences de configuration précises, car les cas d’usage et le matériel disponible peuvent varier considérablement. | Exemple 1 | Exemple 2 | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Si vous exploitez une installation Server Pro pour 300 utilisateurs au total, et que vous prévoyez régulièrement que 30 à 60 de ces utilisateurs compilent des documents en même temps, 8 Go et 7 cœurs (5 cœurs + 5 Go + base de 2 cœurs et 3 Go) devraient fournir des ressources suffisantes pour que vos utilisateurs bénéficient d’un niveau de service élevé et constant. | Pour donner un exemple des exigences matérielles pour un déploiement plus important, une installation Server Pro pour 1 000 utilisateurs au total a été mise en place avec succès à l’aide d’un seul serveur équipé de deux processeurs à 4 cœurs et de 32 Go de mémoire système. Cela a suffi aux besoins de l’équipe au cours de l’année d’utilisation écoulée. | Les clients qui dépassent les limites d’un seul grand serveur peuvent consulter [La mise à l’échelle horizontale](/on-premises/fr/maintenance/horizontal-scaling.md) pour Server Pro. ### Stockage Nous déconseillons l’utilisation de Network File System (NFS)/Amazon EFS/Amazon EBS pour le stockage des projets/de l’historique dans les configurations plus importantes et nous ne les **prendons explicitement pas en charge** pour la mise à l’échelle horizontale. Le comportement de ces systèmes de fichiers n’offre pas les performances et la fiabilité nécessaires à Server Pro lorsqu’il fonctionne à grande échelle. Lorsque le système de fichiers ne peut pas suivre la charge, l’application se bloque à cause d’un trop grand nombre d’opérations d’E/S bloquantes. Ces blocages peuvent entraîner un dépassement des verrous basés sur Redis, ce qui peut à son tour provoquer une corruption des données du projet. Nous recommandons d’utiliser [un stockage objet compatible S3](/on-premises/fr/demarrage/what-is-the-overleaf-toolkit.md) à la place. Les performances lentes de S3 n’affectent alors que le téléversement et le téléchargement des fichiers, ce qui ne fait qu’augmenter le nombre de connexions ouvertes à votre fournisseur S3 et n’affecte donc pas le comportement du reste de l’application. En outre, Server Pro peut définir des délais d’attente raisonnables pour les requêtes S3, ce qui n’est pas possible pour les opérations de système de fichiers/E/S au niveau de l’application. {% hint style="info" %} À titre de référence, GitLab adopte une position similaire en [ne prenant pas en charge NFS/Amazon EFS](https://docs.gitlab.com/ee/administration/nfs.html) dans son offre autogérée. {% endhint %} ### Configuration spécifique à Nginx pour les déploiements de grande taille Par défaut, une instance Overleaf Server limite le nombre de connexions à 768. Cela inclut les connexions WebSocket persistantes, la navigation HTML de premier niveau et les requêtes ajax. Une fois la limite atteinte, l’éditeur peut ne pas réussir à se connecter, la page de l’éditeur peut ne pas se charger entièrement et les requêtes de compilation peuvent échouer. Nginx renverra des réponses avec le statut 500 et consignera `worker_connections are not enough while connecting to upstream` dans `var/log/nginx/error`.log dans le conteneur `sharelatex` . Le [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) paramètre limite le nombre de connexions simultanées que nginx acceptera par worker. Le nombre de workers est contrôlé par le [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) paramètre et est défini à 4 par défaut dans notre configuration nginx. Nginx ne fait pas grand-chose par rapport aux autres parties du système, donc ces limites servent de sécurité pour empêcher qu’un trop grand nombre de connexions ne surcharge le système. Il est préférable de rejeter rapidement quelques connexions excédentaires plutôt que de ralentir chaque connexion. Les instances Overleaf Server exposent des variables d’environnement permettant d’ajuster ces paramètres nginx : * `NGINX_WORKER_PROCESSES` pour [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) (par défaut `4`) * `NGINX_WORKER_CONNECTIONS` pour [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) (par défaut `768`) * `NGINX_KEEPALIVE_TIMEOUT` pour [`keepalive_timeout`](https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout) (par défaut `65`)

Lorsqu’un autre proxy est placé devant le sharelatex conteneur (par exemple pour la terminaison TLS), le NGINX_KEEPALIVE_TIMEOUT dans l’instance Overleaf Server doit être supérieur à celui du proxy précédent. Par exemple, avec un autre processus nginx sur l’hôte Docker nginx-host, voici deux exemples :

* Valeur par défaut `NGINX_KEEPALIVE_TIMEOUT`, utilisez [`keepalive_timeout 60s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (valeur par défaut en amont) dans **nginx-host** * Valeur personnalisée `NGINX_KEEPALIVE_TIMEOUT=100s`, utilisez [`keepalive_timeout 90s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (valeur personnalisée en amont) dans **nginx-host** ### Vitesse du CPU LaTeX est un programme à thread unique, ce qui signifie qu’il ne peut utiliser qu’un seul cœur CPU à la fois. Le processeur est également la principale limitation lors de la compilation d’un document. Par conséquent, plus les performances sur un seul cœur de votre CPU sont élevées, plus vite vous pourrez compiler un document. Davantage de cœurs n’aideront que si vous essayez de compiler plus de documents que vous n’avez de cœurs CPU libres. --- # 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/fr/demarrage/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.