{"id":21491,"date":"2026-09-17T15:05:11","date_gmt":"2026-09-17T13:05:11","guid":{"rendered":"https:\/\/webhosting.de\/apache-scoreboard-serverauslastung-im-detail-monitoring\/"},"modified":"2026-09-17T15:05:11","modified_gmt":"2026-09-17T13:05:11","slug":"monitoraggio-dettagliato-del-carico-di-lavoro-del-server-apache-scoreboard","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/apache-scoreboard-serverauslastung-im-detail-monitoring\/","title":{"rendered":"Apache Scoreboard: comprendere in dettaglio il carico del server"},"content":{"rendered":"<p>L'Apache Scoreboard mi mostra in tempo reale quanti worker stanno leggendo le richieste, inviando risposte o sono inattivi, e lo utilizzo per valutare la <strong>Carico del server<\/strong> senza dover tirare a indovinare. Tramite mod_status accedo in modo strutturato ai dati di stato, interpreto i simboli, misuro la velocit\u00e0 di trasmissione e ne ricavo dati concreti <strong>Fasi di messa a punto<\/strong> da.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<ul>\n  <li><strong>Stato in tempo reale<\/strong> comprendere tutti i lavoratori e individuare rapidamente le strozzature.<\/li>\n  <li><strong>mod_status<\/strong> Garantire la sicurezza e utilizzare in modo efficace ExtendedStatus.<\/li>\n  <li><strong>Cifre chiave<\/strong> come Req\/s, Busy\/Idle e CPU in modo sistematico.<\/li>\n  <li><strong>Simboli<\/strong> interpretare i dati del tabellone e agire in modo mirato.<\/li>\n  <li><strong>Monitoraggio<\/strong> automatizzare e impostare allarmi basati sui dati.<\/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\/09\/apache-serverraum-8371.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Che cos\u2019\u00e8 l\u2019Apache Scoreboard?<\/h2>\n\n<p>Nello Scoreboard, Apache memorizza per ogni worker uno stato attuale, come \u201cLettura\u201d, \u201cInvio\u201d o \u201cInattivo\u201d, e in questo modo posso vedere il <strong>Ripartizione dei compiti<\/strong> dei processi. I dati sono disponibili internamente e vengono trasmessi all\u2019interfaccia tramite mod_status, a scelta in formato HTML o in modalit\u00e0 leggibile dal sistema. L\u00ec controllo i worker occupati, quelli inattivi, il carico della CPU, il tempo di attivit\u00e0, nonch\u00e9 gli accessi e i byte. Trovo particolarmente utile la visione dettagliata dei singoli worker, perch\u00e9 mi permette di individuare i tempi di elaborazione e l\u2019host attivo. In questo modo posso decidere con cognizione di causa se manca capacit\u00e0, se le richieste richiedono troppo tempo o se gli slot Keep-Alive sono bloccati; questi <strong>Trasparenza<\/strong> consente di risparmiare tempo nell'analisi delle cause.<\/p>\n\n<h2>Ecco come accedo tramite mod_status<\/h2>\n\n<p>Con \/server-status apro una pagina HTML di facile consultazione; con \/server-status?auto ottengo un output testuale sintetico per <strong>Monitoraggio<\/strong> e script. Negli ambienti di produzione attivo ExtendedStatus, perch\u00e9 le metriche aggiuntive per ogni worker mi forniscono il contesto necessario. Limito rigorosamente l\u2019accesso alle reti amministrative o a singoli host e non rendo pubblica la pagina. Per una verifica manuale \u00e8 sufficiente una breve sessione del browser; in caso di monitoraggio continuo, integro la visualizzazione automatica in un sistema di monitoraggio. In questo modo mantengo basso il sovraccarico e garantisco la <strong>dati di stato<\/strong> in modo ragionevole.<\/p>\n\n<h2>Valutare la sicurezza della configurazione e il sovraccarico<\/h2>\n\n<p>Proteggo \/server-status in modo sistematico e, a seconda della situazione, scelgo tra l'autorizzazione degli IP, l'autenticazione o un VHost amministrativo interno. ExtendedStatus causa un impatto misurabile, ma nella pratica minimo <strong>Spese generali<\/strong>; lo attivo in modo permanente se utilizzo i dati anche nel monitoraggio, oppure solo temporaneamente per le analisi ad hoc. Una configurazione di esempio chiara mi aiuta a evitare errori:<\/p>\n\n<pre><code>Attiva #\nExtendedStatus On\n\nRendere disponibile lo stato # solo internamente\n\n  SetHandler server-status\n\n  # Variante 1: basata su IP\n  Require ip 10.0.0.0\/8 192.168.0.0\/16 ::1\n\n  # Variante 2: autenticazione Basic (ad es. in aggiunta all\u2019IP)\n  #AuthType Basic\n  #AuthName \"Stato del server\"\n  #AuthUserFile \"\/etc\/httpd\/conf\/.htpasswd\"\n  #Require valid-user\n<\/code><\/pre>\n\n<p>Mantengo la pagina disponibile anche al di fuori dei VHost di produzione (ad esempio tramite un indirizzo interno), in modo che nessuna regola di riscrittura o percorso proxy possa interferire. Al termine delle fasi di debug, mi assicuro che vengano pubblicati solo i dettagli necessari.<\/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\/09\/apache_serveranalyse_6874.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Come interpretare rapidamente le icone del tabellone<\/h2>\n\n<p>In caso di anomalie, controllo innanzitutto le icone, perch\u00e9 una fitta sequenza di R e W indica un carico acuto, mentre molte _ segnalano calma; queste <strong>Codifica<\/strong> accelera la diagnosi. Anche la lettera K mi mostra le connessioni Keep-Alive aperte che, in caso di timeout non adeguato, bloccano i worker. Un'attenzione particolare alla colonna D indica le ricerche DNS che ritardano le risposte. Frequenti voci nella colonna L indicano un logging bloccante e sottosistemi di memoria. Con poche occhiate riesco cos\u00ec a individuare il collo di bottiglia dominante e ad avviare interventi mirati <strong>Misure<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Simbolo<\/th>\n      <th>Significato<\/th>\n      <th>Avviso immediato<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>_<\/td>\n      <td>Lavoratore inattivo<\/td>\n      <td>Sufficiente <strong>Capacit\u00e0<\/strong> disponibile<\/td>\n    <\/tr>\n    <tr>\n      <td>R<\/td>\n      <td>Richiesta di lettura<\/td>\n      <td>Verifica la latenza di rete oppure <strong>Cliente<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>W<\/td>\n      <td>Invio della risposta<\/td>\n      <td>Tempo di elaborazione backend e dimensione dell'output <strong>analizzare<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>K<\/td>\n      <td>Mantenere in vita<\/td>\n      <td>Timeout e associazione degli slot <strong>verificare<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>D<\/td>\n      <td>Ricerca DNS<\/td>\n      <td>Disattivare il Reverse DNS oppure <strong>cache<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>L<\/td>\n      <td>Registrazione<\/td>\n      <td>Registrazione asincrona e <strong>I\/O<\/strong> controllo<\/td>\n    <\/tr>\n    <tr>\n      <td>C<\/td>\n      <td>Chiusura<\/td>\n      <td>Fine normale della connessione, <strong>breve<\/strong> visibile<\/td>\n    <\/tr>\n    <tr>\n      <td>G<\/td>\n      <td>Una conclusione elegante<\/td>\n      <td>Richiesta completata, worker <strong>sgombera<\/strong> all'indirizzo<\/td>\n    <\/tr>\n    <tr>\n      <td>I<\/td>\n      <td>Pulizia in modalit\u00e0 inattiva<\/td>\n      <td>Non critico, operaio <strong>rettificato<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>.<\/td>\n      <td>Inattivo<\/td>\n      <td>Fase di calma, risorse <strong>libero<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Riconoscere modelli e profili di attacco avanzati<\/h2>\n\n<p>Non valuto solo singole condizioni, ma anche le <strong>Durata<\/strong> e distribuzione dei simboli. La presenza di molti stati R prolungati, in concomitanza con una larghezza di banda di rete ridotta, indica la presenza di client lenti o di modelli Slowloris; in tal caso, limito i tempi di lettura per ogni richiesta (ad esempio con RequestReadTimeout) e imposto valori minimi realistici. Se prevalgono gli stati W con un elevato numero di byte per richiesta, il fattore limitante \u00e8 piuttosto la larghezza di banda o lo spazio di archiviazione. Concentrazioni simultanee di stati D e L mi inducono a dare priorit\u00e0 alla risoluzione dei nomi e all\u2019I\/O dei log. \u00c8 fondamentale stabilire se i modelli <strong>ampio<\/strong> (tutti i lavoratori) oppure <strong>locale<\/strong> (solo un VHost o un percorso) \u2013 in questo modo riesco a individuare pi\u00f9 rapidamente gli hotspot nell'applicazione.<\/p>\n\n<h2>Indicatori chiave per l'analisi dei server web<\/h2>\n\n<p>Le richieste al secondo mi indicano la velocit\u00e0 di trasmissione, ma valuto parallelamente anche i byte al secondo e i byte per richiesta per la <strong>carico utile<\/strong>. Il rapporto \"busy-to-idle\" rivela se mancano slot o se le impostazioni sono troppo conservative. Metto in correlazione il carico della CPU con i tempi di risposta per distinguere i casi \"CPU-bound\" da quelli \"I\/O-bound\". L\u2019uptime aiuta a distinguere i riavvii recenti dalle tendenze reali. Da questa combinazione ricavo leve di ottimizzazione concrete per i worker, il keep-alive e <strong>Timeout<\/strong> da.<\/p>\n\n<h2>Valori limite e allarmi nella pratica<\/h2>\n\n<p>Non imposto gli allarmi in base ai valori istantanei, ma alle medie mobili e <strong>Durata<\/strong>. Si sono dimostrate efficaci, ad esempio, le seguenti euristiche: Idle  4:1 nello stesso periodo suggerisce una saturazione. Il valore di Req\/s diminuisce a parit\u00e0 di traffico, mentre Busy rimane costante: in questo caso, spesso la causa \u00e8 da ricercarsi nel backend. Una percentuale K &gt; 50 % nelle ore di punta indica un Keep-Alive troppo generoso. Aggiungo alle soglie degli allarmi di tendenza (tempi di risposta in aumento a parit\u00e0 di carico) e <strong>Stagionalit\u00e0<\/strong> (modelli giornalieri e settimanali), in modo da poter distinguere i cambiamenti reali dal comportamento normale.<\/p>\n\n<h2>Classificare correttamente il file ScoreboardFile<\/h2>\n\n<p>Su alcune piattaforme, Apache scrive i dati di stato in un file \"scoreboard\" e io li salvo in una directory veloce e protetta come \/var\/run\/httpd; questo aumenta la <strong>affidabilit\u00e0<\/strong>. Impedisco che pi\u00f9 istanze utilizzino lo stesso file, altrimenti si rischia di ottenere valori errati. Alcuni strumenti leggono direttamente dal file, rendendo superfluo l\u2019endpoint HTTP. Ci\u00f2 \u00e8 vantaggioso in termini di sicurezza e prestazioni, a condizione che le autorizzazioni siano corrette. Documento il percorso e l\u2019accesso, in modo che la manutenzione e <strong>Monitoraggio<\/strong> rimanere coerenti.<\/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\/09\/apache-serverauslastung-detail-4893.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Caratteristiche specifiche del sistema operativo e dei container<\/h2>\n\n<p>Mi assicuro che i limiti dei descrittori di file, i backlog e i percorsi temporanei siano adeguati al carico di lavoro. In systemd verifico se PrivateTmp o ReadOnlyPaths influenzano il percorso dello scoreboard. Nei container pianifico in modo prudente lo spazio di memoria richiesto per ogni processo\/thread e imposto il percorso dello Scoreboard in una directory scrivibile <strong>Directory di runtime<\/strong>. Per i picchi di carico, modifico i parametri del kernel:<\/p>\n\n<pre><code># Valori sysctl di esempio (da testare e documentare a livello di sistema)\nnet.core.somaxconn = 4096\nnet.ipv4.tcp_max_syn_backlog = 4096\nfs.file-max = 1048576\n<\/code><\/pre>\n\n<p>Inoltre, regolo il parametro `ulimit -n` per il servizio Apache in modo che raggiunga il valore massimo <strong>contemporaneit\u00e0<\/strong> \u00e8 adeguato (regola empirica: FD aperti \u2248 2\u20133 \u00d7 MaxRequestWorkers in configurazioni con un carico elevato sul proxy). Dopo aver apportato le modifiche, controllo nuovamente lo scoreboard per verificare gli effetti.<\/p>\n\n<h2>Casi d'uso tipici: individuare i lavoratori sovraccarichi<\/h2>\n\n<p>Se quasi tutte le slot sono occupate da R o W e compaiono pochissime voci _\u2011, il server raggiunge il proprio <strong>Limite<\/strong>. A quel punto controllo il valore di MaxRequestWorkers, i tempi di risposta e i backend bloccanti. Se l\u2019aggiunta di ulteriori worker non risolve il problema, il collo di bottiglia si trova spesso nell\u2019applicazione, nel database o nello storage. Tramite \/server-status?auto monitoro l\u2019andamento a intervalli regolari, invece di limitarmi a osservare solo istantanee. In questo modo decido se modificare le impostazioni, potenziare la cache o <strong>Scala<\/strong> piano.<\/p>\n\n<h2>Modello delle risorse e formule di capacit\u00e0<\/h2>\n\n<p>Calcolo in anticipo le capacit\u00e0 per evitare di creare colli di bottiglia nella memoria. Per Prefork vale: Memoria \u2248 numero di processi \u00d7 RSS per processo. Per Worker\/Event: Memoria \u2248 numero di processi \u00d7 (RSS per processo) + thread \u00d7 overhead dei thread. Misuro l\u2019RSS effettivo con gli strumenti di sistema e mantengo dei margini di sicurezza. Un piccolo esempio: 20 processi \u00d7 50 MB + 500 thread \u00d7 1 MB danno \u2248 1,5 GB, pi\u00f9 la cache e i buffer del sistema operativo. Da questo calcolo deduco i valori di MaxRequestWorkers, ServerLimit e ThreadsPerChild. Tengo inoltre conto del fatto che moduli come SSL, PHP o il reverse proxy aumentano l\u2019utilizzo di memoria per <strong>Thread<\/strong> possono aumentare; per questo motivo effettuo i test con un carico utile reale, non solo a vuoto.<\/p>\n\n<h2>Interpretare le code e la latenza<\/h2>\n\n<p>Se le richieste rimangono a lungo nello stato \"Accept\" o \"Write\", la latenza percepita aumenta e mi occupo delle lunghezze delle code e del backlog di \"Accept\"; il tabellone fornisce a tal fine preziose <strong>Indicatori<\/strong>. Questo articolo mi fornisce una spiegazione pi\u00f9 approfondita su code, latenze e gestione delle richieste: <a href=\"https:\/\/webhosting.de\/it\/server-web-accodamento-latenza-gestione-delle-richieste-coda-del-server\/\">Code e latenza<\/a>. Partendo da questi presupposti, valuto se i colli di bottiglia si verificano a monte di Apache, all\u2019interno di Apache o a valle. Tolleriamo brevi picchi, ma risolviamo gli ingorghi persistenti intervenendo sulla capacit\u00e0 o sull\u2019architettura. In questo modo impediamo che i timeout si aggravino e che i client <strong>interrompere<\/strong>.<\/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\/09\/apache_scoreboard_office1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Stabilire la connessione al backend e al proxy<\/h2>\n\n<p>Negli ambienti basati su proxy, dalle fasi W deduco se i worker si trovano su <strong>Flussi ascendenti<\/strong> Attendo. ExtendedStatus mi mostra il VHost e la risorsa richiesta; in questo modo posso correlare i percorsi con i backend lenti. Impostando timeout realistici (TimeOut, ProxyTimeout) e verificando il connection pooling, evito che i thread rimangano bloccati inutilmente. Se la pipeline si intasa durante gli upload, regolo le velocit\u00e0 di lettura per ogni client e mi proteggo dai mittenti lenti. Se vengono generate molte risposte di grandi dimensioni, ricorro alla compressione, al chunking e <strong>Caching<\/strong> da prendere in considerazione per ridurre i tempi W.<\/p>\n\n<h2>Configurare il Keep-Alive in modo mirato<\/h2>\n\n<p>Molte voci K indicano la presenza di client che lasciano aperte le connessioni; ci\u00f2 accelera le richieste successive, ma pu\u00f2 occupare gli slot <strong>legare<\/strong>. Impostato i timeout in modo che le ripetizioni effettive ne traggano vantaggio, senza per\u00f2 bloccare troppo a lungo l\u2019inattivit\u00e0. Sui siti molto trafficati, mi \u00e8 d\u2019aiuto un proxy a monte che raggruppa in modo efficiente il Keep-Alive. Per i dettagli sulla messa a punto, utilizzo questa guida: <a href=\"https:\/\/webhosting.de\/it\/impostazione-ottimale-del-timeout-di-keepalive-di-apache-focus-sulle-prestazioni\/\">Impostare il timeout di keep-alive<\/a>. Con un timeout adeguato, la occupazione degli slot diminuisce e il server rimane sotto carico <strong>reattivo<\/strong>.<\/p>\n\n<h2>L'interazione tra HTTP\/2, TLS e MPM<\/h2>\n\n<p>Con HTTP\/2, di solito osservo un minor numero di connessioni K per client, poich\u00e9 pi\u00f9 flussi condividono una connessione <strong>condividere<\/strong>. Event-MPM mostra qui i suoi punti di forza: il Keep-Alive viene gestito in modo pi\u00f9 efficiente, mentre il lavoro attivo rimane di competenza dei thread. Il TLS aumenta il carico sulla CPU per ogni connessione; osservo se percentuali elevate di W sono correlate a un carico elevato sulla CPU e ottimizzo le suite di cifratura e il ripristino della sessione. Nelle viste di stato, per ogni VHost, individuo se prevalgono i percorsi di terminazione HTTP\/2 o TLS e allocco le risorse di conseguenza (ad esempio, pi\u00f9 thread anzich\u00e9 pi\u00f9 processi, se i cambi di contesto sono onerosi).<\/p>\n\n<h2>Ricerca dei DNS e registrazione dei dati sotto controllo<\/h2>\n\n<p>Se la lettera D compare pi\u00f9 volte nel tabellone, controllo il Reverse DNS e attivo una cache locale oppure disattivo le ricerche; questo riduce il <strong>Latenza<\/strong>. Se vedo molte voci \u201cL\u201d, la registrazione rallenta l\u2019elaborazione, quindi distribuisco i file di log, utilizzo uno storage pi\u00f9 veloce o pipeline asincrone. Configuro i log a rotazione in modo da evitare picchi di flush. Parallelmente, misuro gli I\/O in scrittura e i blocchi dei file per eliminare i modelli di blocco. In questo modo recupero tempo di elaborazione e alleggerisco il carico sul <strong>Lavoratore<\/strong>.<\/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\/09\/apache_scoreboard_server_auslastung_4738.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Integrazione nei sistemi di monitoraggio<\/h2>\n\n<p>Raccolgo periodicamente i dati da \/server-status?auto, salvo i valori come serie temporale e visualizzo i dati relativi a \u201cBusy vs Idle\u201d, Req\/s, Bytes\/s e carico della CPU su <strong>Cruscotti<\/strong>. Gli allarmi definiscono soglie relative a slot costantemente pieni, tempi di risposta in aumento o modelli di traffico insoliti. Con le annotazioni contrassegno i deployment, in modo da poter vedere immediatamente gli effetti. Questa cronologia distingue i picchi isolati dalle tendenze reali. In questo modo gestisco la capacit\u00e0 in modo pianificato e prevengo <strong>Sorprese<\/strong>.<\/p>\n\n<h2>Acquisizione automatizzata tramite script<\/h2>\n\n<p>Per controlli rapidi mi basta uno script leggero che analizzi la vista \u201cAuto\u201d e riporti solo i dati essenziali. Mantengo gli intervalli di interrogazione moderati (ad es. 10\u201330 secondi) per ridurre al minimo l\u2019overhead e contrassegno ogni campione con host, VHost e ambiente.<\/p>\n\n<pre><code>#!\/bin\/sh\nURL=\"http:\/\/127.0.0.1\/server-status?auto\"\ncurl -s \"$URL\" | awk -F': ' '\n  \/BusyWorkers\/ {busy=$2}\n  \/IdleWorkers\/ {idle=$2}\n  \/ReqPerSec\/   {rps=$2}\n  \/BytesPerSec\/ {bps=$2}\n  END { printf(\"busy=%s idle=%s rps=%.2f bps=%.0f\\n\", busy, idle, rps, bps) }\n'\n<\/code><\/pre>\n\n<p>In ambienti pi\u00f9 grandi, aggregho inoltre i tempi per worker, li assegno ai VHost e calcolo <strong>Quantili<\/strong> per i tempi di risposta. In questo modo capisco se solo una parte degli utenti riscontra dei problemi o se la maggioranza ne \u00e8 interessata.<\/p>\n\n<h2>MPM e pianificazione della capacit\u00e0<\/h2>\n\n<p>L'MPM definisce il modo in cui Apache gestisce le connessioni; i dati di Scoreboard mi indicano se sono i processi o i thread a costituire il fattore limitante <strong>Fattore<\/strong> . Per la selezione e la messa a punto, metto a confronto Event e Worker, misuro i tempi di inattivit\u00e0, il binding keep-alive e i cambi di contesto. Questo articolo offre un confronto sintetico: <a href=\"https:\/\/webhosting.de\/it\/apache-mpm-event-vs-mpm-worker-ottimizzazione-del-server-web\/\">Evento vs. Lavoratore MPM<\/a>. Dopo aver apportato le modifiche, verifico nuovamente i valori di Busy\/Idle e Req\/s per confermare gli effetti. In questo modo prendo decisioni basate sui dati e aumento la <strong>Efficienza<\/strong>.<\/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\/09\/serverraum-apache-5542.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Riavvio graduale, implementazioni a rotazione e manutenzione<\/h2>\n\n<p>In caso di implementazioni o modifiche alla configurazione, preferisco eseguire un <strong>grazioso<\/strong> Riavvio disattivato. Nel Scoreboard lo riconosco dalla presenza di molti stati G, mentre i nuovi processi si avviano e quelli vecchi terminano in modo ordinato. Pianifico le modifiche graduali in modo da lasciare una capacit\u00e0 inattiva sufficiente: prima riduco il carico, poi eseguo un ricaricamento graduale, infine i nodi rimanenti. Le fasi G prolungate sono un'indicazione del fatto che i vecchi processi sono in attesa di richieste lente: in tal caso, controllo i timeout e il keep-alive per ridurre il tempo di transizione.<\/p>\n\n<h2>Passo dopo passo verso un\u2019analisi approfondita<\/h2>\n\n<p>Attivo mod_status, proteggo l'accesso e abilito ExtendedStatus, in modo da poter visualizzare tutti i <strong>dettagli<\/strong> ottengo. Successivamente controllo la pagina HTML nel browser e imparo lo schema in tempo reale delle icone. Nella fase successiva integro \/server-status?auto nel mio sistema di monitoraggio e convalido le metriche. Quindi ottimizzo uno dopo l\u2019altro: numero di worker, keep-alive, timeout, caching e percorsi dell\u2019applicazione. Misuro nuovamente ogni modifica finch\u00e9 Req\/s, tempo di risposta e Busy\/Idle non rientrano nuovamente nel <strong>Area verde<\/strong> bugia.<\/p>\n\n<h2>Sintesi: Apache Scoreboard come bussola<\/h2>\n\n<p>Apache Scoreboard mi offre una visione chiara e immediatamente utilizzabile del carico di lavoro, dei colli di bottiglia e del comportamento dei <strong>Lavoratore<\/strong>. Con mod_status, ExtendedStatus e un monitoraggio accurato, trasformo i dati grezzi in decisioni affidabili. I simboli e le metriche mi indicano se devo espandere la capacit\u00e0, ridurre i timeout o intervenire sull\u2019applicazione. Una piccola modifica al Keep-Alive o all\u2019MPM pu\u00f2 avere un grande effetto, se i dati sono corretti. Chi sa interpretare correttamente i segnali mantiene Apache sotto carico <strong>reattivo<\/strong> e pianificabile.<\/p>","protected":false},"excerpt":{"rendered":"<p>Scopri come Apache Scoreboard ti aiuta nell'analisi del server web: impara a configurare mod_status, a interpretare le icone di Scoreboard e a utilizzare il monitoraggio di Apache per ottimizzare il carico del server.<\/p>","protected":false},"author":1,"featured_media":21484,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-21491","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":"112","_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 Scoreboard","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":"21484","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21491","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=21491"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21491\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/21484"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=21491"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=21491"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=21491"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}