Perché dovresti mai impostare MaxKeepAliveRequests su qualsiasi cosa tranne che illimitata?

Apache KeepAliveTimeoutesiste per chiudere una connessione keep-alive se una nuova richiesta non viene emessa entro un determinato periodo di tempo. A condizione che l'utente non chiuda il proprio browser / scheda, questo timeout (in genere 5-15 secondi) è ciò che alla fine chiude la maggior parte delle connessioni keep-alive e impedisce che le risorse del server vengano sprecate trattenendo le connessioni indefinitamente.

Ora la MaxKeepAliveRequestsdirettiva pone un limite al numero di richieste HTTP che KeepAliveserviranno una singola connessione TCP (lasciata aperta a causa ). Impostarlo su 0significa che è consentito un numero illimitato di richieste.

Perché dovresti mai impostarlo su qualcosa di diverso da "illimitato"? A condizione che un cliente stia ancora facendo attivamente richieste, che male c'è nel lasciarle accadere sulla stessa connessione keep-alive? Una volta raggiunto il limite, le richieste continuano ad arrivare, solo su una nuova connessione.

Per come la vedo io, non ha senso limitare questo. Cosa mi sto perdendo?

Fondamentalmente, perché Apache non è stato creato per questo. Il problema è l'utilizzo della memoria del server. In molte configurazioni, la generazione del contenuto avviene nello stesso processo della consegna del contenuto, quindi ogni processo crescerà fino alla dimensione della cosa più grande che gestisce. Immagina un processo che si espande a 64 MB a causa di un pesante script php, quindi quel processo gonfio è seduto e serve file statici. Ora moltiplicalo per 100. Inoltre, se ci sono perdite di memoria ovunque, i processi cresceranno senza limiti.

Le impostazioni keepalive devono essere bilanciate in base al tipo di contenuto e al traffico. In generale, la configurazione ottimale ha MaxKeepAliveRequests alto (100-500) e KeepAliveTimeout basso (2-5) per liberarli rapidamente.

So che questa è una vecchia domanda, ma ho fatto un po 'di debug e sembra che (e questo non è vero solo per Apache) MaxKeepAliveRequestsfunziona indipendentemente KeepAliveTimeout.

Ciò significa che la direttiva timeout conta solo per le connessioni permanenti inattive (nessuna lettura o scrittura): se si continua a richiedere al di sotto del timeout, è possibile eseguire virtualmente un numero illimitato di richieste sulla stessa connessione.

Questo potrebbe non essere buono per alcuni motivi, tra cui le connessioni tcp di lunga durata vengono uccise casualmente? In ogni caso, i client http non sono così stupidi e possono gestire MaxKeepAliveRequestsabbastanza bene un'impostazione "bassa" , ad esempio è relativamente facile nel linguaggio di programmazione rilevare se una connessione tcp è stata chiusa dal server e quindi riconnettersi ad essa. Inoltre, la maggior parte dei client http avrà limiti da soli (ad es. I browser chiuderebbero una connessione keep-alive dopo circa 300 secondi).

Uno dei motivi sarebbe il bilanciamento del carico. Una volta stabilita una connessione persistente o http 1.1, il bilanciamento del carico non lo sposterà su un nuovo host fino alla sua chiusura. Se hai un client che effettua un numero enorme di richieste tramite la sua connessione, potresti non ottenere un buon bilanciamento tra i server.

In parte, per impedire a un singolo utente di registrare tutti gli slot di connessione. Senza limiti, un client malintenzionato o mal scritto potrebbe subentrare ad ogni singola connessione disponibile e trattenerla per sempre. Questa non è una grande mitigazione per questo, tuttavia, rispetto a qualcosa come un limite di connessione per IP.

Principalmente bilanciamento del carico, ma in particolare per quanto riguarda la manutenzione. Se si desidera portare un server offline, lasciarlo su 0 connessioni ma consentire il completamento delle connessioni esistenti per un certo periodo di tempo. Mettere un limite al numero di richieste keepalive significa che alla fine gli utenti creeranno con grazia una nuova connessione e saranno spostati su un nuovo server back-end. Probabilmente un modo per segnalare al server che dovrebbe smettere di accettare del tutto i keepalive durante il processo di drenaggio sarebbe ancora meglio, ma per quanto ne so, tale funzionalità non esiste.