Come faccio a selezionare quale MPM Apache usare?

261

Questa è una domanda canonica sulla selezione del giusto MPM httpd di Apache.

Sono un po 'confuso tra i diversi MPM offerti da Apache: "worker", "event", "prefork", ecc.

Quali sono le principali differenze tra loro e come posso decidere quale sarà la migliore per una determinata distribuzione?

— Tiffany Walker
fonte

4

Se stai supportando mod_php, allora stai facendo prefork.

— Zoredache,

6

@Zoredache:? non ha mai menzionato PHP, e anche se lo avesse fatto, mod_php escluderebbe solo l'evento. Oppure ti stai ancora aggrappando a un'osservazione fatta da RL 8 anni fa? L'ultimo bug registrato in PHP relativo

— all'apache

2

Scusate, ho dovuto votare per chiudere questo, è una domanda troppo ampia per rispondere qui.

— symcbean,

1

@symcbean Re: PHP e Threads - Il core di PHP è thread-safe in questi giorni, ma molte altre cose che troverai in cui le persone non si stanno compilando. Sono stato morso di recente lo scorso anno, quindi è ancora un "test (ampiamente) prima di fare affidamento su di esso nella produzione" situazione ...

— voretaq7

A seconda del sistema operativo in uso, potresti non avere nemmeno tutte quelle opzioni disponibili con un'installazione standard.

— John Gardeniers,

415

Ci sono un certo numero di moduli MPM (moduli multi-processing), ma di gran lunga il più diffuso (almeno nelle piattaforme * nix) sono i tre principali: prefork, workere event. In sostanza, rappresentano l'evoluzione del server Web Apache e i diversi modi in cui il server è stato creato per gestire le richieste HTTP entro i vincoli di elaborazione del tempo nel corso della sua lunga storia (in termini di software).

`prefork`

mpm_preforkè .. beh .. è compatibile con tutto. Esegue una serie di processi figlio per soddisfare le richieste e i processi figlio servono solo una richiesta alla volta. Poiché ha il processo del server seduto lì, pronto per l'azione e non ha bisogno di gestire il marshalling dei thread, in realtà è più veloce dei più moderni MPM threaded quando hai a che fare con una singola richiesta alla volta - ma le richieste simultanee ne risentono, poiché vengono fatti attendere in linea fino a quando un processo del server è gratuito. Inoltre, tentando di aumentare il numero di processi figlio di prefork, risuccherai facilmente un po 'di RAM.

Probabilmente non è consigliabile usare prefork a meno che non sia necessario un modulo che non sia thread-safe.

Usa se: hai bisogno di moduli che si rompono quando vengono usati i thread, come mod_php. Anche allora, considera l'utilizzo di FastCGI e php-fpm.

Non usare se: i tuoi moduli non si romperanno nel threading.

`worker`

mpm_workerusa il threading, che è di grande aiuto per la concorrenza. Il lavoratore si allontana da alcuni processi figlio, che a loro volta si allontanano da fili figlio; simile a prefork, alcuni thread di riserva sono tenuti pronti, se possibile, per servire le connessioni in entrata. Questo approccio è molto più gentile sulla RAM, poiché il conteggio dei thread non ha un impatto diretto sull'uso della memoria come il conteggio dei server in prefork. Gestisce anche la concorrenza molto più facilmente, poiché le connessioni devono solo attendere un thread gratuito (che di solito è disponibile) invece di un server di riserva in prefork.

Utilizzare se: si utilizza Apache 2.2 o 2.4 e si esegue principalmente SSL.

Non usare se: non puoi davvero sbagliare, a meno che tu non abbia bisogno di prefork per la compatibilità.

Tuttavia, tieni presente che i gradini sono collegati alle connessioni e non alle richieste , il che significa che una connessione keep-alive mantiene sempre in attesa un thread fino a quando non viene chiuso (il che può richiedere molto tempo, a seconda della configurazione). Ecco perché abbiamo ..

`event`

mpm_eventè molto simile al lavoratore, strutturalmente; è stato appena spostato dallo stato "sperimentale" a "stabile" in Apache 2.4. La grande differenza è che utilizza un thread dedicato per gestire le connessioni mantenute attive e passa le richieste ai thread figlio solo quando è stata effettivamente effettuata una richiesta (consentendo a tali thread di eseguire il backup immediatamente dopo il completamento della richiesta). Questo è ottimo per la concorrenza di client che non sono necessariamente tutti attivi contemporaneamente, ma fanno richieste occasionali e quando i client possono avere un timeout di lunga durata.

L'eccezione qui è con le connessioni SSL; in tal caso, si comporta in modo identico al lavoratore (incollando una determinata connessione a un determinato thread fino alla chiusura della connessione).

Usa if: sei su Apache 2.4 e ti piacciono i thread, ma non ti piace avere thread in attesa di connessioni inattive. A tutti piacciono le discussioni!

Non usare se: Non sei su Apache 2.4 o hai bisogno di prefork per la compatibilità.

Nel mondo odierno di slowloris , AJAX e browser a cui piace multiplexare 6 connessioni TCP (con keep-alive, ovviamente) al tuo server, la concorrenza è un fattore importante nel rendere scalabili e scalabili i tuoi server. La storia di Apache lo ha legato a questo proposito, e mentre in realtà non è ancora all'altezza di nginx o lighttpd in termini di utilizzo o scala delle risorse, è chiaro che il team di sviluppo sta lavorando per costruire un web server che sia ancora rilevante nel mondo di oggi ad alta richiesta di concorrenza.

— Shane Madden
fonte

3

-1: IME, worker riduce solo la dimensione dell'orma httpd di circa il 15% (IIRC Linux riporta COW in RSS che fa sembrare pre-fork come se stesse usando molta più memoria di quanto non faccia). C'è una differenza trascurabile tra l'impronta del kernel per un processo e un thread NPTL. È molto lontano dalla frantumazione della terra. Non capisco perché pensi che attendere e allocare un thread sia più efficiente in termini di pianificazione che attendere / pianificare un processo (pre-biforcato). Né cosa pensi che SSL abbia nel complesso.

— symcbean,

9

@symcbean Quindi stai dicendo che l'utilizzo del 15% di RAM non è significativo? Va bene, ma la mia opinione sarebbe diversa. Le dichiarazioni di prestazione della concorrenza non sono mie. Vedi qui . E la differenza SSL è spiegata chiaramente nella documentazione per l'evento MPM:

The improved connection handling does not yet work for certain connection filters, in particular SSL. For SSL connections, this MPM will fall back to the behaviour of the worker MPM and reserve one worker thread per connection.

— Shane Madden

3

@ShaneMadden `e mentre in realtà non è ancora all'altezza di nginx o lighttpd in termini di utilizzo o scala delle risorse` ho avuto entrambi i sistemi apache floor.

— Kelly Elton,

@ShaneMadden riguardo al problema con SSL e l'evento MPM: Sai se nginx lo gestisce in modo significativamente migliore di apache?

— DASKAjA,

Sembra che se compili apache 2.4 senza conoscere i moduli mpm, viene fornito con un modulo chiamato event mpm module e funziona con mod_php7 (al momento sto cercando mpm perché apache2.4 sta superando il limite di connessione mysql mentre apache 2.2 con lo stesso server mysql è no)

— BioHazard

8

Ecco una buona spiegazione di come funziona con le gif:

https://www.datadoghq.com/blog/monitoring-apache-web-server-performance/

In breve: se hai la 2.4 e hai bisogno di httpd come proxy inverso (dispatcher), allora la tua scelta è un Event MPM

— Yura
fonte

Anche se utilizziamo SSL? Uso apache come proxy e abilitatore SSL su un sito Web non SSL.

— bokan,

@bokan sembra sì, questo è il migliore, ma comunque il proxy è limitato per SSL

— Yura

Wow ~ Il post sul blog è molto meglio della risposta accettata e le gif sono meravigliose! Thankssss. Mi hai salvato la giornata.

— Rick,

6

A partire da febbraio 2018, la documentazione di Apache 2.4 per Event MPM afferma che l'utilizzo di Apache come proxy manterrà la "gestione della connessione migliorata" dal 2.4.24 dal funzionamento come previsto. Vedi la sezione Limitazioni .

Il problema è che, come proxy, il lavoratore non può dire dove si trova la fine della risposta e sarà costretto ad attendere fino a quando non verrà vista l'intera risposta prima di restituire il controllo all'ascoltatore.

Per questo motivo, sembra che l'utilizzo del modello Worker possa essere la soluzione migliore quando apache viene utilizzato come proxy. Non mi è veramente chiaro se ci sono vantaggi per il modello di eventi in un ambiente proxy, ma forse ci sono.

— Andor
fonte

5

Principalmente dipende da quali moduli Apache si desidera utilizzare. Penso che il lavoratore sia generalmente la scelta predefinita, ma alcuni moduli (più vecchi) richiedono il fork e dipendono dal prefork.

Se non hai preferenze, ti consiglio di scegliere la dipendenza preferita dalla tua distribuzione del sistema operativo. Ubuntu, ad esempio, per impostazione predefinita installerà mpm-worker quando si installa Apache2.

— Jeroen
fonte