Ottimizzazione delle prestazioni di Apache: Moduli MPM

  1. Apache Performance Tuning: Memoria di Swap
  2. Apache Performance Tuning: Moduli MPM
  3. Apache Performance Tuning: Direttive MPM
  4. Apache Performance Tuning: Configurazione delle direttive MPM
  5. Come abilitare il Piped Logging in Apache

Tempo di lettura: 3 minuti

La chiave di volta per capire le prestazioni del server Apache è di gran lunga il Multiprocessing Modules (MPMs). Questi moduli determinano la base di come Apache affronta il multiprocesso. Multiprocessing significa eseguire più operazioni simultaneamente in un sistema con più unità di elaborazione centrale (CPU Cores).

Ci sono molti MPM tra cui scegliere; tuttavia, questo articolo si concentra sui moduli più comunemente usati nei server VPS basati su Liquid Web Linux. Questi moduli sono:

  • MPM Prefork
  • MPM Worker
  • MPM Event
  • Altri MPM
  • Quale MPM è il migliore?

MPM Prefork

L’autoregolazione MPM Prefork deriva il suo nome dal modo in cui si biforca o si copia in nuovi processi identici in modo preventivo per aspettare le richieste in arrivo. Un approccio al multiprocesso non basato su thread, MPM Prefork esegue Apache in un singolo processo server principale. Questo genitore è responsabile della gestione di qualsiasi server figlio aggiuntivo che compone il suo serverpool. Mentre si usa MPM Prefork, ogni server figlio gestisce solo una singola richiesta. Questo focus fornisce un completo isolamento dalle altre richieste trattate sul server. MPM Prefork è tipicamente usato per compatibilità quando sono richieste librerie/software non threaded, come mod_php (DSO). Da un punto di vista di ottimizzazione, MPM Prefork può essere molto carente rispetto alle soluzioni multi-threaded, richiedendo molte più risorse per raggiungere livelli di traffico simili a quelli di un MPM threaded. È un uso intensivo di risorse a causa della sua necessità di generare copie complete di Apache per ogni richiesta.

Nota:
Evitare di usare MPM Prefork quando possibile. La sua incapacità di scalare bene con l’aumento del traffico supererà rapidamente l’hardware disponibile nella maggior parte delle configurazioni di sistema.

MPM Worker

Un server web ibrido pre-forking, multi threaded, multiprocessing. Allo stesso modo di MPM Prefork, MPM Worker usa lo stesso approccio con un singolo processo padre master che governa tutti i bambini all’interno del suo pool di server. Tuttavia, a differenza di MPM Prefork, questi figli sono processi multi-threaded che possono gestire decine di thread (richieste) simultaneamente. MPM Worker ha posto le basi per il multiprocessing multi-thread nei server Apache che è diventato stabile in Apache 2.2. La configurazione threaded permette ad Apache di servire centinaia di richieste con facilità mantenendo solo una dozzina di processi figli in memoria. L’MPM Worker rende sia una soluzione ad alta capacità che a basse risorse per il servizio web.

Nota
La direttiva KeepAliveTimeOut attualmente definisce la quantità di tempo in cui Apache aspetta le richieste. Quando si utilizza KeepAlive con MPM Worker usare il più piccolo KeepAliveTimeout possibile (1 secondo preferibilmente).

MPM Event

Basato sul codice sorgente di MPM Worker, MPM Event condivide le direttive di configurazione con MPM Worker. Funziona quasi identico a MPM Worker tranne quando si tratta di gestire le richieste KeepAlive. MPM Event usa un thread Listener dedicato in ogni processo figlio. Questo thread ascoltatore è responsabile di indirizzare le richieste in arrivo ad un thread lavoratore disponibile. Il thread ascoltatore risolve il problema incontrato da MPM Worker che blocca interi thread in attesa del KeepAliveTimeout. L’approccio Listener di MPM Event assicura che i thread worker non siano “bloccati” in attesa della scadenza di KeepAliveTimeout. Questo metodo mantiene il massimo numero di thread di lavoratori che gestiscono il maggior numero possibile di richieste.

Informazioni sul limite del server

Suggerimento:
MPM Event è stabile in Apache 2.4, le versioni precedenti possono usare MPM Worker come alternativa.

Altri MPM

C’è un assortimento di MPM aggiuntivi disponibili. Questi sono tipicamente parte dell’integrazione di Apache in sistemi operativi diversi da quelli basati su Unix. Questi hanno MPM specifici che sono requisiti o che utilizzano Apache sui loro rispettivi tipi di sistema. Questi tipi di MPM vanno oltre l’ambito di questo articolo. Puoi trovare maggiori informazioni su MPM specifici nella sezione MPM Defaults della documentazione ufficiale di Apache.

Nota:
Si raccomanda di stare lontani da MPM sperimentali e instabili. La natura inaffidabile di questi tipi di software li rende insostenibili.

Quale MPM è il migliore?

Quando si considera l’ottimizzazione, è essenziale capire che non esiste una configurazione Apache a taglia unica. Scegliere correttamente un MPM richiede l’analisi di molte variabili in movimento come il traffico, il codice del sito, il tipo di server, il PHP Handler e l’hardware disponibile. Ogni server è unico rendendo il miglior MPM una scelta del tutto soggettiva.

Se il codice della tua applicazione non supporta il multi-threading, allora la tua scelta sarà inevitabilmente MPM Prefork puramente sulla base della compatibilità. MPM Prefork include moduli software come mod_php (DSO). MPM Worker senza KeepAlive funziona molto bene se la tua applicazione è un sistema API bilanciato ad alte prestazioni. La scalabilità e la flessibilità di MPM Event è una scelta solida per l’hosting di più siti di piccole e medie dimensioni in una configurazione di hosting condiviso.

La maggior parte delle configurazioni di server semplici funziona bene sotto la configurazione predefinita autogestita di MPM Event, rendendola un punto di partenza ideale per la messa a punto dell’ottimizzazione. Una volta scelto, un MPM può poi passare alle direttive di configurazione per rivedere quali impostazioni riguardano le prestazioni e l’ottimizzazione del server. Oppure controlla il nostro precedente articolo in questa serie, Apache Performance Tuning: Swap Memory.

Navigazione della serie << Articolo precedente Articolo successivo >>

Lascia un commento