Quale installare: Apache Worker o Prefork? Quali sono i (dis-) vantaggi di ciascuno?

55

Sulla base delle descrizioni di Prefork e Worker MPM, sembra che il tipo di prefork sia in qualche modo obsoleto, ma non riesco davvero a trovare un confronto adeguato dei due tipi.

Cosa vorrei sapere:

Quali sono le differenze tra le due versioni?
Quali sono i (dis-) vantaggi di ciascun tipo di server?
Esistono linee guida di base su quale tipo scegliere in base alle condizioni?
Ci sono grandi differenze di prestazioni tra i due?

apache-2.2 mpm-worker mpm-prefork

— Aron Rotteveel
fonte

2

Vedi Come posso selezionare quale MPM Apache usare?

— Janus Troelsen,

40

Come dicono i documenti, è necessario utilizzare prefork MPM se è necessario evitare il threading per la compatibilità con le librerie non thread-safe. In genere, qualsiasi modulo Apache non banale ( mod_php- o, più precisamente, la miriade di estensioni e librerie a cui si collega - essendo l'esempio canonico) ha una sorta di libreria non thread-safe (o ha non thread- codice di sicurezza), quindi a meno che tu non stia usando un'installazione Apache piuttosto originale, preferirei il prefork MPM.

— womble
fonte

3

Avrei raccomandato il lavoratore MPM, a meno che tu non stia eseguendo PHP. Worker è l'MPM consigliato da apache e offre prestazioni migliori e costi generali inferiori. È solo che lo sviluppatore di PHP non ha mai sentito parlare della sicurezza dei thread che è necessario utilizzare prefork.

— David Pashley,

16

PHP è stato thread-safe per molto tempo. Suggeriscono solo l'uso di pre-forker in quanto non possono controllare ciò che fanno le altre librerie. Smetti di incolpare PHP per le inazioni di altri sviluppatori.

— Alister Bulman,

3

PHP può essere thread-safe (anche se ne dubito) ma tutte le librerie a cui si collega non lo sono sicuramente. Qui eseguiamo alcune applicazioni PHP abbastanza grandi e ogni paio di mesi proviamo a passare da prefork a worker, ma otteniamo subito dati corrotti.

— Aleksandar Ivanisevic,

5

Almeno la variabile ENV che cambia funzione non sarà thread-safe, setlocal php.net/manual/en/function.setlocale.php ne è un esempio comune.

— raggio

4

Una nota: questi problemi non si applicano se PHP è collegato, ad esempio con php-fpmFastCGI. Quindi l'MPM lavoratore va bene - quindi il fpm eseguirà ogni richiesta PHP in un proprio processo mentre l'Apache può eseguire thread. Il problema di sicurezza di PHP-Thread ti impedisce solo di usare mod_php, che esegue PHP all'interno del processo Apache.

— mschuett,

13

La soluzione classica per eseguire estensioni non sicure mentre serve un numero elevato (> 100) di connessioni simultanee è eseguire PHP su fastCGI (mod_fcgid, un modulo apache nativo) e inoltrare richieste dinamiche da un'istanza apache che esegue Worker MPM.

Ciò consentirebbe di scalare da poche centinaia fino a> 1000 connessioni simultanee con una modesta quantità di memoria (4 ~ 8 GB) quando si serve un mix di contenuti statici e dinamici.

Ovviamente, dovresti anche esaminare le soluzioni di memorizzazione nella cache front-end come parte della tua distribuzione generale (memcached, vernice).

In alternativa, esegui l'upgrade ad apache 2.4 e al suo evento nativo MPM, che gestisce la concorrenza in modo molto migliorato (i thread vengono attivati al momento della connessione, non aspettando di essere sottoposti a polling).

— adaptr
fonte

potresti espandere il commento mpm sull'evento? Come si accumula contro mpm-worker?

— Sirex,

Mentre l'MPM lavoratore era già basato su thread, e quindi molto più veloce da avviare e più leggero da eseguire, l'evento MPM non esegue più il polling del socket, ma viene notificato sull'attività; quindi "evento".

— adattamento

quindi dovrebbe funzionare meglio su siti ad alto traffico (13k / sec)?

— Sirex,

6

Sono passati circa 3 anni da quando la domanda è stata pubblicata, ma ti consiglio di andare con MPM lavoratore invece di pre-fork anche se usi PHP, per ottenere prestazioni migliori.

Per quanto riguarda le differenze, il pre-fork è senza thread, quindi il server esegue un processo per ogni richiesta del client (pre-forchette in previsione di nuove richieste in modo che il fork non passi i tempi di risposta). Dal momento che le richieste sono server in un processo separato, questo di solito impone di più alla memoria e alla CPU. Il lavoratore porta il multi-threading che è più leggero e ha un migliore utilizzo della memoria.

— aleemb
fonte

2

Questo è qualcosa di molto particolare per quello che stai servendo. Se stai facendo molte piccole connessioni statiche, i thread sarebbero più leggeri e veloci. Se hai solo poche grandi app generate costantemente, prefork potrebbe avere un vantaggio a causa della sua maturità e stabilità. Perché non solo impostare ciò di cui hai bisogno, testarne uno, scambiare il modulo MPM, riprovare, vedere quale si adatta meglio a te?

— Marcin
fonte

Non è possibile "sostituire" arbitrariamente l'MPM in apache 2.2; è impostato al momento della compilazione.

— adattamento

È possibile con apt o RPM. Debian ha diversi pacchetti Apache 2, a seconda dello stile che preferisci.

— Brendan Byrd,

1

che necessita del tipo e del tipo di traffico che avrai. E anche prima devi capire la differenza principale tra prefork e worker. Spero che l'articolo qui sotto ti aiuti a capire! http://slashroot.in/how-is-nginx-different-from-apache

— Sarath
fonte

2

Preferiamo che le risposte abbiano contenuti, non collegamenti ai contenuti. Se è possibile fornire un riepilogo di ciò che è sul target di collegamento, questa è la migliore pratica. Il collegamento si verifica.

— sysadmin1138

1

La domanda riguardava Apache (nginx non è apache) e i meriti relativi di prefork o thread (nginx non usa nessuno dei due)

— symcbean