> 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/fr/premiers-pas/requirements/hardware-requirements.md). # Exigences matérielles ## Exigences matérielles Lorsque vous dimensionnez le 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 que seulement environ 5 travailleront en même temps, l’installation minimale sera suffisante. Si vous prévoyez qu’une proportion plus élevée travaillera (et compilera) simultanément, vous devriez envisager de provisionner un serveur avec une spécification plus élevée. ### 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 sera également suffisante pour des groupes plus importants où l’utilisation simultanée est moindre, ou lorsqu’il est acceptable que les temps de compilation soient plus longs lors d’une 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 la [Dépannage](/on-premises/fr/support/troubleshooting.md) section. {% endhint %} ### Mise à l’échelle En règle générale, pour fournir un niveau de service élevé et constant, il faut ajouter 1 cœur de CPU et 1 Go de mémoire à l’installation minimale pour chaque tranche de 5 à 10 utilisateurs simultanés. Cela ne doit être pris 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 à des temps de compilation plus longs lors d’une utilisation intensive influencent tous le niveau de ressources à provisionner. Nombre 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 sous-jacent disponible peuvent être très variés. | Exemple 1 | Exemple 2 | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Si vous exploitez une installation Server Pro pour 300 utilisateurs au total et que vous vous attendez régulièrement à ce 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 suffisamment de ressources pour que vos utilisateurs bénéficient d’un niveau de service constamment élevé. | 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 d’utiliser Network File System (NFS)/Amazon EFS/Amazon EBS pour le stockage des projets/de l’historique dans les grandes configurations et nous ne le **prennons pas en charge** pour la mise à l’échelle horizontale. Le comportement de ces systèmes de fichiers ne fournit pas les performances et la fiabilité nécessaires à Server Pro lorsqu’il fonctionne à grande échelle. Lorsque le système de fichiers ne parvient 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 d’objets compatible S3](/on-premises/fr/premiers-pas/what-is-the-overleaf-toolkit.md) à la place. De mauvaises performances S3 n’affectent alors que le téléversement et le téléchargement des fichiers, ce qui entraîne uniquement un nombre plus élevé de connexions ouvertes à votre fournisseur S3 et n’affecte donc pas le comportement du reste de l’application. De plus, Server Pro peut définir des délais d’attente raisonnables sur 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 auto-hébergé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 niveau supérieur et les requêtes AJAX. Une fois la limite atteinte, l’éditeur pourrait ne pas réussir à se connecter, la page de l’éditeur pourrait ne pas se charger entièrement et les requêtes de compilation pourraient échouer. Nginx renverra des réponses de statut 500 et consignera `worker_connections ne sont pas suffisantes lors de la connexion à l’upstream` dans `var/log/nginx/error`.log à l’intérieur du `conteneur sharelatex.` conteneur. 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 paramètre [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) et est défini par défaut à 4 dans notre configuration nginx. Nginx ne fait pas beaucoup de travail comparé aux autres parties du système, donc ces limites servent de protection pour éviter 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 pour 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`)

Lorsque vous exécutez un autre proxy devant le conteneur 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 processeur LaTeX est un programme à thread unique, ce qui signifie qu’il ne peut utiliser qu’un seul cœur de CPU à la fois. Le CPU est également la principale limite lors de la compilation d’un document. Par conséquent, plus les performances d’un seul cœur de votre CPU sont élevées, plus vous pourrez compiler un document rapidement. 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://overleaf-pro.ayaka.space/on-premises/fr/premiers-pas/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.