questa settimana Debian rilascia apache 2.2
ecco quali pacchetti richiederà di aggiornare:
apache2 2.2.16-6
apache2-mpm-prefork
apache2-utils
apache2.2-bin
apache2.2-common
apache2-mpm-prefork cattura la mia attenzione: cosa significa esattamente prefork? quali implicazioni ha? quali alternative esistono?
uno sguardo ad apt-cache/synaptic e una ricerca in rete ci dice che ci sono un certo numero di moduli mpm*, ma di gran lunga il più usato (almeno su piattaforme su linux) è prefork e ci sono tre principali alternative: prefork, worker, e event. In sostanza, essi rappresentano l'evoluzione del web server Apache, e diversi modi in cui il server è stato costruito per gestire le richieste HTTP ottimizzando le risorse disponibili per i bisogni del tempo, durante la sua lunga (in termini di software) storia, e con la upcoming 2.4 il team di sviluppo si ta concentrando sul enuove applicazioni client e gli ambienti server cloud prefork mpm_prefork è il modello storicamente più utilizzato, ha il vantaggio di essere compatibile con tutti i sistemi operativi e di essere molto sicuro/affidabile, per queste ragioni è il default. Questo modello prevede di avviare un certo numero di processi figli per servire le richieste e ciascuno dei processi figli servono solo una richiesta alla volta. Prevede un processo master che ha il compito di avviare un numero costante di processi a cui poi passare l'elaborazione vera e propria, secondo molte prove risulta più veloce rispetto alle MPM più moderne fintanto che si ha a che fare con una unica richiesta per volta e in genere con mod_php, tuttavia richiede più risorse di memoria, dato che i processi, che occupano memoria, sono fatti attendere in linea fino a quando un processo del server sia disponibile. Inoltre, nel tentativo di scalare l'applicazione aggiungendo processi figli, si potrebbero facilmente arrivare al limite di risorse della macchina. Probabilmente non sarà obbligatorio utilizzare prefork se non avete bisogno di un modulo che non sia thread-safe. Da usare se: Avete bisogno di moduli che non sono thread-safe, come mod_php. Anche in qul caso, si potrebbe considerare le alternative FastCGI e php-fpm. Non utilizzare se: avete forti constrain di memoria o applicazioni altamente parallele worker mpm_worker utilizza il threading - che è un importante aiuto per la concorrenza. worker avvia alcuni processi manager, che a sua volta avviano alcuni thread figlio, fin qui sembra simile a prefork, ma la differenza sta nella grandezza dei processi avviati, in pratica questi sono più piccoli e leggeri, mentre in prefork è come se l'intero server si moltiplicasse in memoria. questo approccio produce una concorrenza migliore perché una nuova richiesta entrante attende solo l'avvia di un nuovo thread invece che la duplicazione del server come in prefork. Da usare se: Sei su Apache 2.2, o 2.4 e puoi risparmiare un po' di ram facendo qualche test di carico in più sulla tua applicazione Non utilizzare se: applicazioni mission critical in cui non volete prendere il minimo rischio, applicazioni che volete far girare su più piattafome e volete escludere che possano verificarsi problemi connessi ai thread. Tuttavia, si noti che i thread sono collegati a connessioni e non "richieste" - il che significa che una connessione keep-alive mantiene sempre attivo un thread fino a quando viene chiusa (che potrebbe essere un lungo periodo di tempo, a seconda dell'applicazione). Ed è per questo che abbiamo ... event mpm_event è molto simile a worker concettualmente, ed è appena stato promosso da 'sperimentale' a 'stable' in Apache 2.4. La grande differenza è che utilizza un thread dedicato per affrontare connessioni keep-alive, e invia le richieste ai thread figlio solo quando una richiesta è stata effettivamente eseguita (permettendo a quei threads di liberare risorse subito dopo che la richiesta è stata gestita). Questo è molto importante per la concorrenza di clients che non sono necessariamente tutti attivi contemporaneamente, ma fanno brevi richieste occasionali, e quando i client potrebboro avere un timeout keep-alive lungo. L'eccezione è con connessioni SSL, in questo caso, si comporta esattamente come worker (assegna a una determinata connessione un determinato thread fino a quando la connessione si chiude). Da usare se: Sei su Apache 2.4 e vuoi i threads, ma non vuoi threads in attesa di connessioni inattive. tutti vogliono risparmiare risorse! Non utilizzare se: non sei su Apache 2.4 o hai bisogno di prefork per la compatibilità.
