> ## 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. # Configuration matérielle requise ## Configuration matérielle requise Lors du dimensionnement du matériel destiné à 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 ne prévoyez qu'environ 5 personnes travaillant en même temps, l'installation minimale suffira. Si vous prévoyez qu'une proportion plus importante travaille (et compile) simultanément, envisagez un serveur aux caractéristiques plus élevées. ### Installation minimale Une configuration de base d'au moins 2 cœurs et 3 Go de mémoire est requise pour un fonctionnement de base avec environ 5 utilisateurs simultanés. Cette configuration minimale suffira également pour des groupes plus importants dont l'utilisation simultanée est moindre, ou lorsque des temps de compilation plus longs sont acceptables en période de forte utilisation. Si vous envisagez d'utiliser un système de fichiers basé sur NFS (Network File System) pour votre petite instance, consultez cette section de la page [Dépannage](/fr/on-premises/support/troubleshooting). ### Montée en charge En règle générale, pour offrir un niveau de service élevé et constant, il convient d'ajouter 1 cœur de processeur et 1 Go de mémoire à l'installation minimale pour chaque tranche de 5 à 10 utilisateurs simultanés. Ceci ne doit être considéré qu'à titre indicatif : des facteurs tels que la taille des documents typiques (les documents volumineux consomment davantage de ressources de compilation), la fréquence des compilations et la tolérance aux temps de compilation plus longs en période de forte utilisation influent tous sur le dimensionnement nécessaire. Beaucoup de nos clients cherchent à déployer Server Pro à l'échelle de toute leur organisation ou au sein de grandes équipes. Dans ces situations, il nous est difficile de donner des recommandations précises de configuration, car les cas d'usage et le matériel 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 prévoyez régulièrement que 30 à 60 d'entre eux 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 offrir à vos utilisateurs un niveau de service élevé et constant. | Pour donner un exemple de configuration matérielle pour un déploiement plus important, une installation Server Pro pour 1 000 utilisateurs au total a été mise en place avec succès sur 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 page [Mise à l'échelle horizontale](/fr/on-premises/maintenance/horizontal-scaling) pour Server Pro. ### Stockage Nous déconseillons l'utilisation de Network File System (NFS)/Amazon EFS/Amazon EBS pour le stockage des projets et de l'historique dans les installations de grande taille, et ces solutions ne sont explicitement **pas prises en charge** pour la mise à l'échelle horizontale. Ces systèmes de fichiers n'offrent 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 en raison d'un trop grand nombre d'opérations d'E/S bloquantes. Ces blocages peuvent entraîner le dépassement de verrous basés sur Redis, ce qui peut à son tour corrompre les données des projets. Nous recommandons plutôt d'utiliser un [stockage objet compatible S3](/fr/on-premises/getting-started/what-is-the-overleaf-toolkit). Des performances S3 lentes n'affectent que l'envoi et le téléchargement des fichiers, ce qui se traduit seulement par un nombre accru de connexions ouvertes vers votre fournisseur S3, sans affecter le comportement du reste de l'application. De plus, Server Pro peut définir des délais d'expiration raisonnables pour les requêtes S3, ce qui n'est pas possible pour les opérations de système de fichiers/d'E/S au niveau de l'application. À 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) pour son offre autogérée. ### Configuration spécifique à Nginx pour les déploiements de grande taille Par défaut, l'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 cette limite atteinte, l'éditeur peut ne pas parvenir à 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 à l'intérieur du conteneur `sharelatex`. Le paramètre [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) limite le nombre de connexions simultanées que nginx accepte 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), fixé à 4 par défaut dans notre configuration nginx. Nginx effectue relativement peu de travail par rapport aux autres composants du système ; ces limites servent donc de garde-fou pour éviter qu'un trop grand nombre de connexions ne submerge le système. Il est préférable de rejeter rapidement quelques connexions excédentaires plutôt que de ralentir toutes les connexions. 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 conteneur `sharelatex` (par exemple pour la terminaison TLS), la valeur de `NGINX_KEEPALIVE_TIMEOUT` dans l'instance Overleaf Server doit être supérieure à celle du proxy en amont. Par exemple, avec un autre processus nginx sur l'hôte Docker nginx-host, voici deux exemples : * Valeur par défaut de `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 monothread, ce qui signifie qu'il ne peut utiliser qu'un seul cœur de processeur à la fois. Le processeur est également le principal facteur limitant lors de la compilation d'un document. Par conséquent, plus les performances monocœur de votre processeur sont élevées, plus vos documents compileront rapidement. Davantage de cœurs ne seront utiles que si vous essayez de compiler plus de documents que vous n'avez de cœurs libres. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.