Perché l'evento Apache MPM funziona male?

Question

L'MPM Evento non ha esattamente lo stesso design di Nginx, ma è stato chiaramente progettato per rendere i keepalive più tenibili e l'invio di file statici più veloce. Mi risulta che il MPM evento è un po 'fuorviante perché:

1. Sebbene la connessione viene passato al kqueue/epoll,
2. determinati moduli molto importanti come mod_gzip e mod_ssl bloccheranno/consumano un filo fino la risposta è fatto,
3. e questo è un problema per file di grandi dimensioni, ma probabilmente non per i documenti HTML PHP-generato, ecc

Purtroppo, Apache continua a perdere quota di mercato, e la maggior parte benchmark sono dannando per l'evento MPM. I benchmark sono viziati o l'evento MPM è davvero negativo rispetto a Nginx? Anche con queste limitazioni, nel traffico normale (non dannoso) e nei file più piccoli, dovrebbe essere alquanto competitivo con Nginx. Ad esempio, dovrebbe essere competitivo per i documenti generati da PHP tramite php-fpm su connessioni lente perché il documento verrà memorizzato nel buffer (anche se è ssl'd e gzip'd) e inviato in modo asincrono. Sia le connessioni SSL che quelle non SSL che utilizzano la compressione o meno non dovrebbero funzionare in modo significativamente diverso da quello che avrebbero in Nginx su un tale carico di lavoro.

Quindi perché non risplende in vari benchmark? Che cosa c'è che non va? O cosa c'è che non va nei benchmark? Un sito importante lo utilizza come un appello all'autorità che può eseguire?

Answer 1

Per me, le differenze che dominano operative sono che nell'evento:

• movimentatori (plugin responsabile della generazione della risposta) sono sincroni - se si sta eseguendo sia computazione o I/O essi saranno impegnare un filo
• il nucleo deve utilizzare serrature cross-thread proteggere le strutture di dati chiave perché è multi-threaded per supportare tanti di queste richieste sincrone

Ecco perché ad alto volume server come nginx (o Apache Traffic Serv er o qualsiasi moderno proxy commerciale/ad alte prestazioni) di solito viene avanti.

IMO I proiettili nella tua domanda sono un po 'off-line, SSL e deflate non stanno davvero contribuendo molto alle differenze qui in quanto sono entrambi i filtri che non contribuiscono realmente a problemi di scalabilità o addirittura legano httpd al suo tradizionale Le API garantiscono il ciclo di vita di una richiesta o di una connessione. I filtri come questi (rispetto ai gestori o al filtro principale responsabile per l'I/O di basso livello) sono probabilmente l'ultimo dei problemi legati al modello di elaborazione.

Ma io non penso che sia così difficile da confrontare per tutti tranne i carichi di lavoro più estremi o sistemi estremamente limitati. La maggior parte dei benchmark che ho visto sono di pessima qualità, per una ragione o per l'altra.

Penso che in gran parte le persone vogliano quello che oggi chiamano un server web per essere un proxy per un server di applicazioni più sofisticato (Java EE, PHP, ecc.) E un server progettato per spostare I/O nel modo più efficiente senza che il bagaglio dell'API stia andando avere il vantaggio

Answer 2

È più lento di nginx perché Apache con l'evento MPM è (molto) approssimativamente equivalente a un proxy HTTP event-driven (nginx, varnish, haproxy) davanti a Apache con l'MPM worker.Event è worker, ma piuttosto che consegnare ogni nuova connessione a un thread per la sua durata, i thread dell'evento MPM passano la connessione a un thread secondario che lo spinge in una coda o lo chiude se keep-alive è spento o è scaduto.

Il vero vantaggio dell'evento su worker è l'utilizzo delle risorse. Se è necessario sostenere 1.000 connessioni simultanee, l'MPM worker ha bisogno di 1.000 thread, mentre l'evento MPM può farcela con 100 thread attivi e 900 connessioni inattive gestiti nella coda degli eventi. L'evento MPM utilizzerà una frazione delle risorse dell'MPM worker in quella ipotetica, ma lo svantaggio è ancora lì: ognuna di queste richieste è gestita da un thread separato che deve essere programmato dal kernel e come tale incorrerà nel costo di cambiare contesto.

D'altra parte abbiamo nginx che utilizza il modello di eventi stesso come suo schedulatore. Nginx semplicemente elabora quanto più lavoro su ogni connessione che può prima di passare a quello successivo. Non è richiesto alcun cambio di contesto aggiuntivo.

L'unico caso di utilizzo in cui l'evento MPM brilla davvero è quello di gestire una configurazione in cui è in esecuzione un'applicazione pesante in Apache e per conservare le risorse dei thread inattivi durante la conservazione, è necessario distribuire un proxy (come nginx) davanti all'apache. Se il tuo front end non ha altri scopi (ad esempio contenuto statico, proxy verso altri server, ecc ...), l'evento MPM gestisce che usa il caso splendidamente ed elimina la necessità di un proxy.