> ## 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. # Requisiti hardware ## Requisiti hardware Quando predisponi l'hardware per eseguire Overleaf, il fattore principale da considerare è quanti utenti simultanei eseguiranno compilazioni. Ad esempio, se hai una licenza per 100 utenti in totale ma prevedi che solo \~5 lavorino contemporaneamente, l'installazione minima sarà sufficiente. Se prevedi che una percentuale maggiore lavori (e compili) contemporaneamente, dovresti valutare un server con specifiche più elevate. ### Installazione minima Per le operazioni di base con circa 5 utenti simultanei è necessario un requisito minimo di 2 core e 3 GB di memoria. Questo requisito minimo è sufficiente anche per gruppi più numerosi con un utilizzo simultaneo ridotto, oppure quando è accettabile che i tempi di compilazione si allunghino nei momenti di maggiore utilizzo. Se stai valutando l'uso di un file system basato su NFS (Network File System) per la tua piccola istanza, consulta questa parte della sezione [Risoluzione dei problemi](/it/on-premises/support/troubleshooting). ### Scalabilità Come regola generale, per garantire un livello di servizio elevato e costante, all'installazione minima va aggiunto 1 core CPU e 1 GB di memoria ogni 5-10 utenti simultanei. Questa indicazione va presa solo come linea guida, poiché fattori come le dimensioni dei documenti tipici (i documenti più grandi consumano più risorse di compilazione), la frequenza con cui gli utenti compilano e la tolleranza verso tempi di compilazione più lunghi durante i picchi di utilizzo influiscono tutti sul livello di risorse necessario. Molti dei nostri clienti intendono distribuire Server Pro a livello di intera organizzazione o in team di grandi dimensioni. In queste situazioni è difficile per noi consigliare requisiti di configurazione specifici, perché i casi d'uso e l'hardware disponibile possono variare molto. | Esempio 1 | Esempio 2 | | - | - | | Se esegui un'installazione di Server Pro per 300 utenti in totale e prevedi regolarmente che 30-60 di essi compilino documenti contemporaneamente, 8 GB e 7 core (5 core + 5 GB + la base di 2 core e 3 GB) dovrebbero fornire risorse sufficienti per garantire agli utenti un livello di servizio costantemente elevato. | Come esempio dei requisiti hardware per una distribuzione più ampia, un'installazione di Server Pro per 1.000 utenti in totale è stata configurata con successo usando un singolo server dotato di due processori a 4 core e 32 GB di memoria di sistema. Questa configurazione si è dimostrata sufficiente per le esigenze del team nell'ultimo anno di utilizzo. | I clienti che superano i limiti di un singolo server di grandi dimensioni possono consultare [Scalabilità orizzontale](/it/on-premises/maintenance/horizontal-scaling) per Server Pro. ### Archiviazione Sconsigliamo l'uso di Network File System (NFS)/Amazon EFS/Amazon EBS per l'archiviazione di progetti e cronologia nelle configurazioni più grandi e **non lo supportiamo** esplicitamente per la scalabilità orizzontale. Il comportamento di questi file system non garantisce le prestazioni e l'affidabilità necessarie a Server Pro quando opera su larga scala. Quando il file system non riesce a reggere il carico, l'applicazione si blocca a causa di troppe operazioni di I/O bloccanti. Questi blocchi possono causare il superamento dei lock basati su Redis, che a loro volta possono portare alla corruzione dei dati dei progetti. Consigliamo invece di usare uno [storage a oggetti compatibile con S3](/it/on-premises/getting-started/what-is-the-overleaf-toolkit). Prestazioni S3 lente influiscono solo sull'upload e sul download dei file, il che comporta soltanto un numero maggiore di connessioni aperte verso il tuo provider S3 e non influisce sul comportamento del resto dell'applicazione. Inoltre, Server Pro può impostare timeout ragionevoli sulle richieste S3, cosa non possibile a livello applicativo per le operazioni di file system/I/O. Come riferimento, anche GitLab adotta una posizione simile, [non supportando NFS/Amazon EFS](https://docs.gitlab.com/ee/administration/nfs.html) nella sua offerta self-managed. ### Configurazione specifica di Nginx per distribuzioni di grandi dimensioni Per impostazione predefinita, l'istanza di Overleaf Server limita il numero di connessioni a 768. Questo valore include le connessioni Websocket persistenti, la navigazione HTML di primo livello e le richieste ajax. Una volta raggiunto il limite, l'editor potrebbe non riuscire a connettersi, la pagina dell'editor potrebbe non caricarsi completamente e le richieste di compilazione potrebbero fallire. Nginx restituirà risposte con stato 500 e registrerà `worker_connections are not enough while connecting to upstream` in `var/log/nginx/error`.log all'interno del container `sharelatex`. L'impostazione [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) limita il numero di connessioni simultanee che nginx accetta per ogni worker. Il numero di worker è controllato dall'impostazione [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) ed è impostato a 4 per impostazione predefinita nella nostra configurazione di nginx. Nginx svolge poco lavoro rispetto ad altre parti del sistema, quindi questi limiti fungono da protezione per evitare che troppe connessioni sovraccarichino il sistema. È preferibile scartare presto alcune connessioni in eccesso piuttosto che rallentare tutte le connessioni. Le istanze di Overleaf Server espongono variabili d'ambiente per regolare queste impostazioni di nginx: * `NGINX_WORKER_PROCESSES` per [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) (predefinito `4`) * `NGINX_WORKER_CONNECTIONS` per [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) (predefinito `768`) * `NGINX_KEEPALIVE_TIMEOUT` per [`keepalive_timeout`](https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout) (predefinito `65`) Quando esegui un altro proxy davanti al container `sharelatex` (ad es. per la terminazione TLS), il valore di `NGINX_KEEPALIVE_TIMEOUT` nell'istanza di Overleaf Server deve essere maggiore di quello del proxy precedente. Ad esempio, con un altro processo nginx sull'host Docker nginx-host, ecco due esempi: * Valore predefinito di `NGINX_KEEPALIVE_TIMEOUT`: usa [`keepalive_timeout 60s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (valore predefinito in upstream) in **nginx-host** * Valore personalizzato `NGINX_KEEPALIVE_TIMEOUT=100s`: usa [`keepalive_timeout 90s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (valore personalizzato in upstream) in **nginx-host** ### Velocità della CPU LaTeX è un programma a thread singolo, il che significa che può usare un solo core della CPU alla volta. La CPU è anche il principale fattore limitante durante la compilazione di un documento. Di conseguenza, più sono elevate le prestazioni single-core della tua CPU, più velocemente potrai compilare un documento. Un numero maggiore di core è utile solo se stai cercando di compilare più documenti rispetto ai core CPU liberi disponibili. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.