Skip to main content

​
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.

​
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. I clienti che superano i limiti di un singolo server di grandi dimensioni possono consultare Scalabilità orizzontale 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. 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 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 limita il numero di connessioni simultanee che nginx accetta per ogni worker. Il numero di worker è controllato dall’impostazione 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 (predefinito 4)
  • NGINX_WORKER_CONNECTIONS per worker_connections (predefinito 768)
  • NGINX_KEEPALIVE_TIMEOUT per 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 (valore predefinito in upstream) in nginx-host
  • Valore personalizzato NGINX_KEEPALIVE_TIMEOUT=100s: usa keepalive_timeout 90s (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.
Last modified on October 4, 2026