{"id":20730,"date":"2026-08-17T11:52:23","date_gmt":"2026-08-17T09:52:23","guid":{"rendered":"https:\/\/webhosting.de\/apache-event-mpm-vs-worker-mpm-webserver-tuning-optimierung\/"},"modified":"2026-08-17T11:52:23","modified_gmt":"2026-08-17T09:52:23","slug":"apache-mpm-event-vs-mpm-worker-ottimizzazione-del-server-web","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/apache-event-mpm-vs-worker-mpm-webserver-tuning-optimierung\/","title":{"rendered":"Apache Event MPM vs Worker MPM: un potente acceleratore per server web moderni in caso di carichi elevati"},"content":{"rendered":"<p>Spiegher\u00f2 in due frasi perch\u00e9 la scelta del <strong>Apache MPM<\/strong> influisce in modo evidente sulla velocit\u00e0 di trasmissione, sulla latenza e sulla stabilit\u00e0 in condizioni di carico elevato. A tal proposito, metto a confronto concretamente Event MPM e Worker MPM in contesti caratterizzati da connessioni Keep-Alive di lunga durata, HTTP\/2 e un elevato livello di parallelismo, ricavandone chiare raccomandazioni di ottimizzazione.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<p>Per permetterti di cogliere immediatamente i concetti pi\u00f9 importanti, riassumo brevemente i punti chiave ed evidenzio in grassetto le parole chiave decisive. Da questi punti ricavo pi\u00f9 avanti operazioni concrete e configurazioni, che spiego in modo pratico. Valuto entrambi gli MPM in modo coerente sulla base di profili di carico realistici con numerose connessioni. In questo modo potrai capire immediatamente quale modulo si distingue nel tuo stack. L\u2019elenco ti fornir\u00e0 una scorciatoia per prendere decisioni fondate nell\u2019ambito delle operazioni quotidiane.<\/p>\n<ul>\n  <li><strong>Evento<\/strong> Disaccoppia l'Idle-Keep-Alive dai thread delle richieste e garantisce la scalabilit\u00e0 in presenza di numerose connessioni.<\/li>\n  <li><strong>Lavoratore<\/strong> \u00c8 efficace con le richieste brevi, ma occupa molti thread in caso di keep-alive prolungato.<\/li>\n  <li><strong>HTTP\/2<\/strong> trae vantaggi misurabili dall'evento grazie a una gestione efficiente del multiplexing.<\/li>\n  <li><strong>Risorse<\/strong>: L'evento mantiene bassi i livelli di RAM\/CPU per ogni richiesta attiva.<\/li>\n  <li><strong>Compatibilit\u00e0<\/strong>: I moduli thread-safe sono obbligatori, mod_php rimane un ambiente prefork.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/serverraum-webserverturbo-4837.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Perch\u00e9 Worker ed Event sono in testa alla classifica<\/h2>\n\n<p>Nella mia azienda moderna punto decisamente su <strong>Discussioni<\/strong>, poich\u00e9 occupano meno RAM per connessione rispetto ai processi. In passato, Prefork garantiva sicurezza con moduli non thread-safe, ma presenta difficolt\u00e0 di scalabilit\u00e0 in presenza di molte connessioni. Oggi dominano i modelli Worker ed Event, poich\u00e9 gestiscono in modo efficiente un gran numero di utenti simultanei. Ci\u00f2 risulta particolarmente vantaggioso con il Keep-Alive attivo e HTTP\/2, dove le connessioni rimangono aperte a lungo. \u00c8 proprio qui che si nota <strong>Evento<\/strong> i suoi punti di forza, poich\u00e9 non occupa i preziosi thread di richiesta con connessioni inattive.<\/p>\n\n<h2>MPM Apache Worker: architettura e limiti<\/h2>\n\n<p>Definisco i worker come un ibrido tra processi e <strong>Discussioni<\/strong>, in cui ogni processo figlio dispone di un thread listener e di numerosi thread server. Una richiesta viene assegnata a un thread, riceve una risposta e successivamente libera nuovamente il thread. Se la connessione rimane aperta, lo stesso thread rimane associato a tale connessione. Ci\u00f2 causa inattivit\u00e0 quando molti client attendono a lungo o inviano solo piccole richieste sporadiche. Chi utilizza i worker dovrebbe quindi dimensionare consapevolmente i pool di thread e i limiti; a tal fine pu\u00f2 consultare la mia breve <a href=\"https:\/\/webhosting.de\/it\/pool-di-thread-ottimizzazione-del-server-workerhosting-threadpool\/\">Ottimizzazione del pool di thread<\/a> utilizzarlo come punto di partenza.<\/p>\n\n<h2>MPM Event di Apache: spiegazione dell'event loop<\/h2>\n\n<p>Descrivo un evento come \u201cworker pi\u00f9 ciclo di eventi\u201d, ovvero <strong>ascoltatore<\/strong>-Thread che mettono in attesa le connessioni inattive. Il listener accetta nuove connessioni, inoltra le richieste attive ai thread di lavoro liberi e successivamente recupera la connessione. In questo modo, i thread di richiesta operano solo quando vi \u00e8 un flusso di dati. Centinaia o migliaia di client possono quindi rimanere aperti senza bloccare i thread. Proprio questo <strong>Parcheggio<\/strong> rende Event cos\u00ec efficiente con i tipici carichi di lavoro HTTP\/1.1 e HTTP\/2.<\/p>\n\n<h2>Evento vs. Worker: differenze sotto carico<\/h2>\n\n<p>Valuto sempre entrambi gli MPM in condizioni reali <strong>Carico<\/strong> con tempi di keep-alive prolungati. Il worker raggiunge rapidamente il limite perch\u00e9 le connessioni inattive occupano i thread, che quindi non sono disponibili per le nuove richieste. L'evento mantiene liberi i pool di thread e sposta le connessioni inattive nel ciclo degli eventi. In questo modo, il numero di utenti gestibili contemporaneamente aumenta notevolmente, mentre le latenze rimangono stabili. Chi ha bisogno di elementi su cui basare le proprie decisioni, farebbe bene a confrontare casi concreti <a href=\"https:\/\/webhosting.de\/it\/threading-modello-server-event-driven-hosting-confronto-serverperf\/\">Modelli di server basati sugli eventi<\/a> con i pool di thread nei test di carico.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/ApacheWebserverMeeting2573.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Compatibilit\u00e0: moduli e configurazioni tipiche<\/h2>\n\n<p>Per prima cosa controllo il <strong>Moduli<\/strong>, poich\u00e9 sia Worker che Event richiedono la sicurezza dei thread. I classici stack mod_php non sono adatti, motivo per cui Prefork continua ad avere senso in questo caso. Se invece PHP viene eseguito tramite PHP-FPM o FastCGI, opto chiaramente per Event. Lo stesso vale per i reverse proxy verso server di applicazioni, microservizi o backend Go\/Node. In tali configurazioni, Worker e soprattutto <strong>Evento<\/strong> la sua forza senza compromessi in termini di compatibilit\u00e0.<\/p>\n\n<h2>Configurazione: le direttive pi\u00f9 importanti<\/h2>\n\n<p>Ti presento in forma sintetica le linee guida fondamentali, in modo che tu possa comprenderle bene e <strong>personalizzato<\/strong>. MaxRequestWorkers limita il numero di richieste elaborate contemporaneamente; con Event spesso \u00e8 possibile impostare un valore pi\u00f9 alto, poich\u00e9 le connessioni inattive non causano blocchi. ThreadsPerChild definisce il numero di thread per processo; un valore troppo basso riduce la produttivit\u00e0, mentre uno troppo alto sovraccarica la CPU. ServerLimit imposta il limite per i processi e quindi il limite massimo per le richieste parallele nell\u2019insieme. Con KeepAliveTimeout puoi controllare per quanto tempo le connessioni rimangono aperte; pi\u00f9 alto \u00e8 il valore, maggiori sono i vantaggi <strong>Evento<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/webserver-turbo-mpm-comparison-8394.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Confronto tabellare: Worker vs. Event<\/h2>\n\n<p>Riassumo le caratteristiche principali in una sintesi <strong>Tabella<\/strong> insieme, in modo da poter individuare immediatamente le differenze. Non sostituisce un test di carico, ma ti aiuta a focalizzare l\u2019attenzione sulle caratteristiche fondamentali. Leggi i punti da sinistra a destra e abbinali al tuo profilo di traffico. In questo modo troverai rapidamente l\u2019MPM pi\u00f9 adatto alla tua architettura. L\u2019attenzione \u00e8 chiaramente rivolta alla scalabilit\u00e0, al fabbisogno di risorse e al comportamento con <strong>Mantenere in vita<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Criterio<\/th>\n      <th>Worker MPM<\/th>\n      <th>Evento MPM<\/th>\n      <th>Effetto<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Gestione del Keep-Alive<\/td>\n      <td>Il thread rimane associato alla connessione<\/td>\n      <td>Le connessioni inattive vengono messe in attesa dall'event loop<\/td>\n      <td>L'evento mantiene liberi i thread di richiesta<\/td>\n    <\/tr>\n    <tr>\n      <td>Impiego delle risorse<\/td>\n      <td>Pi\u00f9 fili intrecciati al minimo<\/td>\n      <td>Meno thread bloccati in stato di inattivit\u00e0<\/td>\n      <td>Minore utilizzo di RAM\/CPU per ogni richiesta attiva<\/td>\n    <\/tr>\n    <tr>\n      <td>Latenza sotto carico<\/td>\n      <td>Parti prima<\/td>\n      <td>Rimane stabile pi\u00f9 a lungo<\/td>\n      <td>Migliore reattivit\u00e0<\/td>\n    <\/tr>\n    <tr>\n      <td>Compatibilit\u00e0 con HTTP\/2<\/td>\n      <td>In ordine<\/td>\n      <td>Molto efficiente<\/td>\n      <td>Vantaggi del multiplexing<\/td>\n    <\/tr>\n    <tr>\n      <td>Configurazione<\/td>\n      <td>MaxRequestWorkers, ThreadsPerChild, ServerLimit<\/td>\n      <td>Immediatamente, oltre all'ottimizzazione dell'event loop<\/td>\n      <td>L'evento consente un maggiore utilizzo delle risorse<\/td>\n    <\/tr>\n    <tr>\n      <td>Compatibilit\u00e0<\/td>\n      <td>Sono necessari moduli a prova di thread<\/td>\n      <td>Allo stesso modo, preferibilmente con PHP-FPM<\/td>\n      <td>Prefork rimane un'opzione di mod_php<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Applicazione pratica: flusso di lavoro di messa a punto e misurazione<\/h2>\n\n<p>Parto sempre da una linea di base pulita <strong>Monitoraggio<\/strong> e i dati di log. Successivamente, modifico gradualmente i valori di MaxRequestWorkers e ThreadsPerChild e misuro la latenza, il tasso di errore e il carico della CPU. Testo KeepAliveTimeout a livelli, poich\u00e9 il tempo ideale dipende fortemente dal comportamento del client. A questo punto vale la pena effettuare un confronto tra Event e Worker utilizzando strumenti come ab, wrk o JMeter. Solo quando le metriche appaiono corrette, fisso il <strong>Profili<\/strong> e documenta gli indicatori chiave.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/apache_mpm_techoffice_4721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Quando il prefork rimane una scelta sensata<\/h2>\n\n<p>Ricorro a Prefork quando il codice non \u00e8 assolutamente thread-safe <strong>Moduli<\/strong> devono essere eseguiti. In questo caso, l'isolamento per ogni processo \u00e8 pi\u00f9 importante della scalabilit\u00e0. In cambio, accetto un fabbisogno di RAM nettamente superiore per ogni connessione. Per le applicazioni legacy che non possono essere adattate, questa rimane spesso la soluzione pi\u00f9 realistica. Tuttavia, non appena utilizzo PHP-FPM o altri server di applicazioni esterni, preferisco <strong>Evento<\/strong> chiaramente.<\/p>\n\n<h2>Il contesto del web hosting e la scelta del provider<\/h2>\n\n<p>Nel contesto dell'hosting prendo in considerazione i profili MPM, perch\u00e9 spesso su una macchina sono presenti molti host virtuali <strong>corsa<\/strong>. Event offre in questo caso l'utilizzo pi\u00f9 efficiente delle risorse, in particolare con HTTP\/2 e TLS. Se il mio stack richiede PHP-FPM, imposto Event come impostazione predefinita. Per una panoramica generale e una verifica tecnica, \u00e8 utile un breve <a href=\"https:\/\/webhosting.de\/it\/webserver-lavoratori-modelli-prefork-lavoratori-eventi-mpm-serverperf\/\">Confronto tra Prefork, Worker ed Event<\/a> prima della scelta finale. Chi svolge questi compiti otterr\u00e0 risultati nettamente migliori <strong>Tempi di risposta<\/strong> per euro.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/entwickler_apachempm_9821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Compatto delle migliori pratiche<\/h2>\n\n<p>Lo uso sistematicamente <strong>PHP-FPM<\/strong> oppure altri server di applicazioni esterni, affinch\u00e9 Event possa esprimere appieno il proprio potenziale. Successivamente, ottimizzo i parametri MaxRequestWorkers e ThreadsPerChild in base ai core della CPU e alla RAM e verifico i limiti massimi del sistema. In presenza di molti client inattivi, scelgo Event, imposto KeepAliveTimeout su un valore volutamente pi\u00f9 alto e monitoro le latenze. Per carichi di lavoro con richieste molto brevi e un keep-alive moderato, Worker \u00e8 sufficiente, purch\u00e9 i moduli rimangano thread-safe. Senza un monitoraggio continuo del carico dei thread, degli errori e <strong>Latenze<\/strong> Non prendo decisioni definitive.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/serverraum-performance-4096.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Esempi concreti di configurazione per Event e Worker<\/h2>\n<p>Fornisco due profili minimalisti che utilizzo come punto di partenza e che poi perfeziono sulla base dei valori misurati. \u00c8 fondamentale che: <strong>MaxRequestWorkers = ServerLimit \u00d7 ThreadsPerChild<\/strong>. Parto dal budget di RAM e dal fabbisogno per thread (compresi moduli, TLS, buffer) e aumento gradualmente.<\/p>\n<pre><code>Esempio #: Event MPM (HTTP\/2, PHP-FPM)\nServerLimit 16\nThreadLimit 256\nThreadsPerChild 64\nMaxRequestWorkers     1024\nStartServers 4\nMaxConnectionsPerChild 10000\n\nKeepAlive On\nMaxKeepAliveRequests  100\nKeepAliveTimeout 15\n\n# Opzionale e da regolare solo dopo aver effettuato delle misurazioni:\n# ListenBacklog 1024\n# ThreadStackSize     1048576   # 1 MB, solo se i moduli lo consentono\n# AsyncRequestWorkerFactor 2    # Ottimizzazione dell'event loop, di solito lasciare il valore predefinito\n\n# HTTP\/2\nProtocols h2 http\/1.1\n# H2MaxSessionStreams  100-200  # Regolare con precisione in base alla capacit\u00e0 del backend\n<\/code><\/pre>\n<pre><code>Esempio #: Worker MPM (richieste brevi, Keep-Alive moderato)\nServerLimit 8\nThreadLimit 256\nThreadsPerChild 50\nMaxRequestWorkers     400\nStartServers 4\nMaxConnectionsPerChild 5000\n\nKeepAlive On\nMaxKeepAliveRequests  100\nKeepAliveTimeout 3\nProtocols http\/1.1\n<\/code><\/pre>\n<p>Tengo <strong>MaxConnectionsPerChild<\/strong> (Alias: MaxRequestsPerChild) diverso da 0, per individuare eventuali perdite graduali. <strong>KeepAliveTimeout<\/strong> Lo imposto volutamente a un valore pi\u00f9 alto per Event, poich\u00e9 le connessioni inattive sono economiche; per Worker lo mantengo basso per non bloccare i thread.<\/p>\n\n<h2>Ottimizzazione di HTTP\/2 con Event<\/h2>\n<p>Quando si tratta di <strong>HTTP\/2<\/strong>, che i browser aprono poche connessioni e molte <strong>Streaming<\/strong> multiplexare. In questo modo, il collo di bottiglia si sposta dal numero di connessioni verso un'allocazione equa dei thread e la capacit\u00e0 del backend. Con Event, i thread rimangono liberi finch\u00e9 uno stream \u00e8 in attesa; ci\u00f2 attenua i picchi di latenza. Leve pratiche:<\/p>\n<ul>\n  <li><strong>H2MaxSessionStreams<\/strong>: Di solito mi muovo nell'intervallo 50\u2013200. Un valore troppo alto genera effetti \u201chead-of-line\u201d nel backend, mentre uno troppo basso spreca il parallelismo.<\/li>\n  <li><strong>Lavoratori MaxRichiesta<\/strong>: Con Event posso aumentare il livello, purch\u00e9 la RAM e la CPU lo consentano. Osservo i percentili 95\u00b0 e 99\u00b0 della latenza all\u2019aumentare del parallelismo.<\/li>\n  <li><strong>TLS<\/strong>: Grazie ad ALPN e alle moderne suite di cifratura, riduco i costi dell'handshake; inoltre, Event ne trae ulteriore vantaggio, poich\u00e9 le fasi di inattivit\u00e0 tra i picchi di traffico vengono gestite in modo efficiente.<\/li>\n<\/ul>\n\n<h2>Limiti del sistema operativo e backlog dei socket<\/h2>\n<p>Prima di ogni test di carico verifico i limiti del sistema, altrimenti non \u00e8 l\u2019MPM a limitare le prestazioni, ma il kernel. Per un numero elevato di connessioni, in particolare, scalare:<\/p>\n<ul>\n  <li><strong>Descrittori di file<\/strong>: ulimit -n e systemd <code>LimiteNOFILE<\/code> lo aumento, ad esempio, a 65536 o oltre; Apache necessita di un FD per ogni socket, log e pipe.<\/li>\n  <li><strong>arretrato<\/strong>: <code>net.core.somaxconn<\/code> e <code>tcp_max_syn_backlog<\/code> Imposto un valore adeguato (ad es. 1024\u20134096) affinch\u00e9 la coda di accettazione non vada in overflow.<\/li>\n  <li><strong>Intervallo di porte<\/strong> (nel caso di proxy inverso): <code>intervallo_porta_locale<\/code> aumentavo (ad es. da 10.000 a 65.000) quando erano presenti molte connessioni in uscita simultanee verso i backend.<\/li>\n  <li><strong>FIN\/Timeout<\/strong>: Attenzione a <code>tcp_fin_timeout<\/code>: se \u00e8 troppo aggressivo pu\u00f2 causare interruzioni della connessione; io modifico solo in base alle misurazioni.<\/li>\n<\/ul>\n<p>Documento ogni modifica al kernel, indicandone la motivazione, e la verifico effettuando una nuova misurazione del carico. In assenza di prove, l'impostazione predefinita \u00e8 solitamente quella corretta.<\/p>\n\n<h2>Monitoraggio e ricerca dei guasti nella pratica quotidiana<\/h2>\n<p>Attivo <strong>Stato esteso<\/strong> e utilizza server-status per verificare lo <strong>Classifica<\/strong>-leggere gli stati. Nella sezione Event vedo molti socket inattivi\/keep-alive, senza che i thread di lavoro siano sfruttati appieno. Nel log degli errori compare il messaggio \u201eserver reached <strong>Lavoratori MaxRichiesta<\/strong> \u201cimpostazione, valutare la possibilit\u00e0 di aumentare il valore di MaxRequestWorkers\", il server sta gi\u00e0 raggiungendo il limite; aumento con cautela e monitoro RAM\/CPU e il tasso di errore.<\/p>\n<ul>\n  <li><strong>Campi di misura<\/strong>: Nei log di accesso registro i tempi di risposta (ad es. %D\/%T), i codici di stato e i byte; metto in correlazione i picchi con la CPU e l'I\/O.<\/li>\n  <li><strong>Sintomi nei lavoratori<\/strong>: Molte connessioni keep-alive inattive, thread occupati a 100 %, latenza in aumento, 503\/504 \u2013 indice di thread bloccati.<\/li>\n  <li><strong>Sintomi durante l'evento<\/strong>: I thread listener sono molto carichi, ma i thread worker sono liberi \u2013 nella maggior parte dei casi si tratta di un limite di rete o del backend, non dell'MPM.<\/li>\n  <li><strong>Graceful-Reload<\/strong>: Applico le modifiche con <code>apachectl -k graceful<\/code> in modo che i liquidi presenti possano defluire correttamente.<\/li>\n<\/ul>\n\n<h2>Pianificazione della capacit\u00e0: dai core e dalla RAM a MaxRequestWorkers<\/h2>\n<p>Faccio un calcolo pragmatico: quanta RAM per thread, pi\u00f9 il buffer, voglio assegnare? Per TLS, i filtri e i moduli pi\u00f9 comuni, faccio una stima prudente di alcuni MB per thread. Quindi imposto <strong>Lavoratori MaxRichiesta<\/strong> in modo tale che i picchi di carico nei percentili 95 e 99 vengano gestiti senza swap. A livello di CPU vale quanto segue: i thread che superano il numero di core sono utili solo se non richiedono costantemente un tempo di esecuzione elevato. Con Event mi permetto di utilizzare valori pi\u00f9 alti, poich\u00e9 le fasi di inattivit\u00e0 hanno un costo minimo.<\/p>\n<ul>\n  <li><strong>Regole generali<\/strong>: Inizio con 32\u201364 thread per processo, 4\u201316 processi; successivamente misurazione e regolazione.<\/li>\n  <li><strong>ThreadStackSize<\/strong>: Se la RAM \u00e8 scarsa e i moduli lo consentono, riduco la dimensione dello stack (con cautela, effettuando uno stress test).<\/li>\n  <li><strong>MaxKeepAliveRequests<\/strong>: Di solito lascio l'impostazione predefinita; con i client \"chiacchieroni\", un valore pi\u00f9 alto pu\u00f2 ridurre l'overhead.<\/li>\n<\/ul>\n\n<h2>Scenari con proxy inverso e connessioni al backend<\/h2>\n<p>Mi piace particolarmente utilizzare Event nei backend delle app perch\u00e9 <strong>Prese frontali<\/strong> parcheggia in modo efficiente, mentre il lavoro vero e proprio si svolge nel backend. \u00c8 quindi fondamentale il pooling dei <strong>Connessioni al backend<\/strong> (mod_proxy):<\/p>\n<ul>\n  <li><strong>Keep-Alive verso il backend<\/strong>: Lasciare attivo per risparmiare handshake; dimensione dei pool (<em>max<\/em> per ciascuna destinazione) in base alla capacit\u00e0 del backend.<\/li>\n  <li><strong>Timeout del proxy<\/strong>: Definire chiaramente i timeout, in modo che i backend in sospeso non occupino i thread del frontend.<\/li>\n  <li><strong>HTTP\/2 verso il backend<\/strong>: Quando possibile, utilizzo H2 (ad es. intern h2c) per ridurre il numero di connessioni pur aumentando il numero di stream \u2013 Event si integra bene con questa soluzione.<\/li>\n<\/ul>\n<p>Osservo in modo mirato le percentuali di latenza tra frontend e backend; se aumenta solo il tempo di elaborazione del backend, l'ottimizzazione dell'MPM da sola non basta: in tal caso devo regolare le dimensioni dei pool, i timeout o le risorse del backend.<\/p>\n\n<h2>Strategia di implementazione e migrazione da Worker a Event<\/h2>\n<p>Procedo per fasi ben definite: per prima cosa controllo il <strong>Elenco dei moduli<\/strong> (apachectl -M) per verificare la sicurezza dei thread. Tutto ci\u00f2 che non \u00e8 thread-safe (come il classico mod_php) deve essere rimosso o isolato. Successivamente attivo Event, imposto valori iniziali prudenti ed eseguo i test di carico sull\u2019ambiente di staging. Durante il rollout, inizio con una parte del traffico (Canary), confronto le metriche e solo allora procedo con il rollout su larga scala.<\/p>\n<ul>\n  <li><strong>comandi<\/strong>: Come da prassi di distribuzione, disattivare e riattivare i moduli MPM (ad es. a2dismod\/a2enmod) e riavviare correttamente il sistema.<\/li>\n  <li><strong>Piano di riserva<\/strong>: Ho preparato un profilo \u201cworker\u201d nel caso in cui un modulo si comporti in modo anomalo durante un evento.<\/li>\n  <li><strong>Documentazione<\/strong>: Documento ogni modifica apportata ai limiti, ai parametri HTTP\/2 e ai valori del kernel con misurazioni \"prima e dopo\".<\/li>\n<\/ul>\n\n<h2>Un occhio di riguardo alla sicurezza e alle prestazioni TLS<\/h2>\n<p>Per quanto riguarda il TLS, ho notato che gli handshake richiedono un elevato carico di CPU e, in condizioni di carico elevato, possono aumentare la latenza. Con <strong>Ripresa della sessione<\/strong> Grazie alla scelta di algoritmi di cifratura moderni, riduco i costi, mentre gestisco in modo efficiente le fasi di inattivit\u00e0. In combinazione con HTTP\/2 e ALPN, evito ulteriori roundtrip. Importante: i buffer TLS e i parametri OpenSSL contribuiscono all\u2019impronta di RAM per ogni thread; ne tengo conto nella pianificazione della capacit\u00e0.<\/p>\n\n<h2>Tolleranza agli errori e degrado graduale<\/h2>\n<p>Sto pianificando in vista di un sovraccarico: la CPU \u00e8 satura o Apache raggiunge <strong>Lavoratori MaxRichiesta<\/strong>, non voglio una valanga di tentativi di riprova. Impostiamo timeout chiari, pagine di errore esaurienti e limiti di frequenza sui proxy a monte. Con Event, sotto pressione, ne rimangono di pi\u00f9 <strong>Discussioni<\/strong> libere per il lavoro effettivo, mentre le connessioni inattive vengono messe in attesa: \u00e8 proprio questa riserva che consente al sistema di rimanere operativo pi\u00f9 a lungo, fino a quando il carico non diminuisce nuovamente o non interviene lo scaling automatico.<\/p>\n\n<h2>Riassumendo brevemente<\/h2>\n\n<p>Nella mia attivit\u00e0 odierna punto su <strong>Evento<\/strong>, non appena il mio stack utilizzer\u00e0 moduli thread-safe e PHP-FPM. Questo approccio riduce i thread occupati nelle connessioni inattive, mantiene stabile il tempo di risposta e aumenta il numero di utenti serviti in parallelo. Worker rimane un'opzione valida per richieste brevi con un keep-alive moderato, quando Event non \u00e8 adatto per motivi organizzativi. Riservo Prefork per configurazioni con moduli non thread-safe o codice obsoleto. Con test di carico chiari, una messa a punto accurata delle direttive e un visibile <strong>Monitoraggio<\/strong> riesco a portare Apache a una velocit\u00e0 massima in modo riproducibile.<\/p>","protected":false},"excerpt":{"rendered":"<p>Apache Event MPM vs Worker MPM: scopri quale MPM offre le migliori prestazioni per l'ottimizzazione dei moderni server web e quando \u00e8 consigliabile utilizzare il modulo Event.<\/p>","protected":false},"author":1,"featured_media":20723,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20730","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"89","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Apache MPM","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20723","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20730","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/comments?post=20730"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20730\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/20723"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=20730"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=20730"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=20730"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}