E 'necessario mettere Unicorn dietro Nginx (o Apache)

Question

Sono un po' confuso su questa architettura. Su uno dei progetti a cui sto lavorando, Unicorn è stato scelto come server Rails. Ed è messo dietro il server web Nginx. Come ho capito Unicorn è un server web perfettamente funzionante e non abbiamo in programma di ospitare altre applicazioni Rails sulla stessa istanza del server.

Quindi la mia domanda sarebbe: quali sono i vantaggi di avere ulteriore livello a catena:

client -> nginx -> unicorn -> unicorn worker 

Answer 1

Unicorn non è stato progettato per gestire i clienti "lenti". Si può leggere di più su questo nel file di aiuto PHILOSOPHY:

La maggior parte dei parametri di riferimento che abbiamo visto non vi dico questo, e unicorno non si preoccupa client lenti ... ma si dovrebbe.

Un "client lento" può essere qualsiasi client al di fuori del datacenter. Il traffico di rete all'interno di una rete locale è sempre più veloce del traffico che attraversa al di fuori di esso. Le leggi della fisica non consentono diversamente.

Le connessioni persistenti sono state introdotte in HTTP/1.1 per ridurre la latenza dalla connessione stabilita e TCP avvio lento. Sprecano anche risorse del server quando i client sono inattivi.

Connessioni persistenti significa che uno dei processi di unicorno (a seconda dell'applicazione, può essere molto affamato di memoria) trascorre una notevole quantità di tempo inattivo mantenendo la connessione attiva e non facendo altro. Essendo a thread singolo e utilizzando l'I/O di blocco, un worker non può servire altri client mantenendo una connessione attiva. Quindi l'unicorno non implementa connessioni persistenti.

Se le risposte dell'applicazione sono maggiori del buffer del socket o se si gestiscono richieste di grandi dimensioni (caricamenti), i processi di lavoro saranno anche colti dalla velocità della connessione client. Non si dovrebbe consentire a unicorno di servire i clienti al di fuori della rete locale.