Trova e correggi 15 colli di bottiglia delle prestazioni

"Bottleneck" è un termine meravigliosamente descrittivo. Descrive un vincolo artificiale su qualche forma di comunicazione, interazione o trasferimento di informazioni. E porta a credere che una combinazione magica di fortuna, denaro e ingegno possa rompere quel collo di bottiglia e far fluire tutte le cose buone.

Il problema con i colli di bottiglia delle prestazioni è che possono essere difficili da identificare. È la CPU? Il network? Un pezzo di codice goffo? Spesso, il colpevole più ovvio è in realtà a valle di qualcosa di più grande e più mistificante. E quando gli enigmi sulle prestazioni rimangono irrisolti, la direzione IT potrebbe trovarsi di fronte alla scelta di Hobson tra ammettere l'ignoranza e inventare scuse.

Fortunatamente, come per le diagnosi mediche o il lavoro investigativo, l'esperienza aiuta. Attingendo ai nostri anni di indagine e sperimentazione, abbiamo raccolto 15 dei disturbi più probabili e suggerito rimedi per aiutare le operazioni IT a individuare e risolvere i problemi di prestazioni.

Alcuni di questi colli di bottiglia sono più evidenti di altri. Molto probabilmente, hai qualcosa da dire su alcuni tuoi subdoli spoiler (e ci piacerebbe sentire i tuoi racconti su di loro). Tuttavia, identificando gli speed killer comuni in tutte le discipline IT, speriamo di dare il via alla tua ricerca per creare l'infrastruttura più performante consentita dalle tue risorse.

No. 1: probabilmente non sono i server

Gli aggiornamenti del server erano soliti fare la differenza, motivo per cui la vecchia sega "Quando tutto il resto fallisce, lancia più hardware" persiste ancora oggi. In alcuni casi è ancora vero. Ma quanto dell'IT è davvero così intensivo in termini di elaborazione? In generale, puoi risparmiare un sacco di tempo e denaro allontanando il tuo bulbo oculare dall'hardware del server. L'estremità inferiore dello spettro dei server ha una potenza più che sufficiente per gestire le attività quotidiane.

Ecco un esempio concreto. Su una rete di oltre 125 utenti, un vecchio controller di dominio Windows sembrava pronto per essere sostituito. Questo server eseguiva originariamente Windows 2000 Server ed è stato aggiornato a Windows Server 2003 qualche tempo fa, ma l'hardware è rimasto invariato. Questo HP ML330 con una CPU da 1 GHz e 128 MB di RAM funzionava come controller di dominio Active Directory con tutti i ruoli AD FSMO, eseguendo servizi DHCP e DNS e IAS (Internet Authentication Services).

Melassa, giusto? In effetti, in realtà ha funzionato bene. La sua sostituzione è stata un HP DL360 G4 con una CPU da 3 GHz, 1 GB di RAM e unità SCSI da 72 GB con mirroring. Trasportando tutti questi servizi, non esegue quasi nessun carico e la differenza di prestazioni è impercettibile.

È facile identificare le applicazioni che consumeranno tutta la CPU e la memoria, ma tendono ad essere piuttosto specializzate. Per quasi tutto il resto, l'umile scatola delle merci farà il trucco.

No. 2: accelera queste domande

Puoi creare l'applicazione più elegante al mondo, ma se l'accesso ai server di database back-end crea un collo di bottiglia, i tuoi utenti finali o clienti non saranno soddisfatti. Quindi ottimizza le query del database e massimizza le prestazioni.

Tre misure di base possono aiutarti a migliorare le prestazioni delle query. Innanzitutto, la maggior parte dei prodotti database include strumenti (come DB2 UDB per iSeries Visual Explain) che possono analizzare la query durante lo sviluppo, fornendo feedback sulla sintassi e sui tempi approssimativi delle varie sezioni delle istruzioni SQL. Utilizzando queste informazioni, individua le parti più lunghe della query e suddividile ulteriormente per vedere come potresti abbreviare il tempo di esecuzione. Alcuni prodotti di database includono anche strumenti di consulenza sulle prestazioni, come Automatic Database Diagnostic Monitor di Oracle, che forniscono consigli (come suggerire di creare un nuovo indice) per velocizzare le query.

Successivamente, attiva gli strumenti di monitoraggio del database su un server di staging. È possibile utilizzare un prodotto di monitoraggio di terze parti, come NetVigil di Fidelia, se il database non dispone del supporto per il monitoraggio. Con i monitor abilitati, generare traffico sul server database utilizzando script di test di carico. Esamina i dati raccolti per vedere come sono state eseguite le tue query sotto carico; queste informazioni possono portare a ulteriori modifiche alle query.

Se disponi di risorse server sufficienti per imitare abbastanza fedelmente il tuo ambiente di produzione di carichi di lavoro misti, puoi eseguire un terzo ciclo di ottimizzazione delle query utilizzando uno strumento di test di carico, come OpenSTA, oltre al monitoraggio del database per vedere come si comportano le tue query insieme ad altre applicazioni che colpiscono il Banca dati.

Man mano che le condizioni del database cambiano, con l'aumento del volume, l'eliminazione di record e così via, continuare a eseguire test e ottimizzazioni. Spesso ne vale la pena.

N. 3: qual è il costo della protezione antivirus?

La protezione antivirus sui server critici è un requisito fondamentale, soprattutto per i server Windows. Tuttavia, l'impatto può essere doloroso. Alcuni scanner antivirus sono più invadenti di altri e possono ridurre in modo significativo le prestazioni del server.

Prova a eseguire test delle prestazioni con e senza lo scanner antivirus in esecuzione per determinare l'impatto. Se vedi un netto miglioramento senza lo scanner, è il momento di cercare un altro fornitore. Controlla anche le caratteristiche specifiche. Disabilita le scansioni in tempo reale e molto spesso aumenterai le prestazioni.

Non importa quanto ben scritta la tua logica aziendale, quando la distribuisci nel livello intermedio, dovrai ottimizzare l'ambiente di runtime del server delle applicazioni per massimizzare le prestazioni.

Come uno stereo vintage con una gran quantità di manopole per modificare la qualità del suono, i server delle applicazioni di fornitori come BEA, IBM e Oracle forniscono una serie vertiginosa di controlli. Il trucco sta nel ruotare le manopole nel modo giusto, a seconda degli attributi dell'applicazione.

N. 4: massimizzare il livello intermedio

Non importa quanto ben scritta la tua logica aziendale, quando la distribuisci nel livello intermedio, dovrai ottimizzare l'ambiente di runtime del server delle applicazioni per massimizzare le prestazioni.

Come uno stereo vintage con una gran quantità di manopole per modificare la qualità del suono, i server delle applicazioni di fornitori come BEA, IBM e Oracle forniscono una serie vertiginosa di controlli. Il trucco sta nel ruotare le manopole nel modo giusto, a seconda degli attributi dell'applicazione.

Ad esempio, se la tua applicazione è ricca di servlet, ti consigliamo di abilitare la memorizzazione nella cache dei servlet. Allo stesso modo, se la tua applicazione utilizza molte istruzioni SQL per supportare un'ampia base di utenti, ti consigliamo di abilitare la memorizzazione nella cache delle istruzioni preparate e impostare la dimensione massima della cache in modo che sia abbastanza grande da supportare il carico di lavoro previsto.

Una delle aree principali in cui l'ottimizzazione delle prestazioni può davvero aiutare è con il pool di connessioni del database. Imposta le connessioni minime o massime su un valore troppo basso e sei certo di creare un collo di bottiglia. Impostali su un valore troppo alto e probabilmente vedrai un rallentamento derivante dall'overhead aggiuntivo necessario per mantenere il pool di connessioni più grande.

Se si conosce il carico di lavoro previsto, ottimizzare il runtime del server delle applicazioni attivando gli strumenti di monitoraggio delle prestazioni come Tivoli Performance Viewer per WebSphere di IBM su un server delle applicazioni di staging. Genera la quantità di carico di lavoro che ti aspetti utilizzando uno strumento di generazione del carico, quindi salva i risultati del monitoraggio e riproducili per analizzare quali manopole devono essere regolate.

Durante la produzione, è una buona idea attivare il monitoraggio passivo a basso sovraccarico per tenere sotto controllo il runtime. Se il carico di lavoro cambia nel tempo, ti consigliamo di eseguire una nuova revisione delle prestazioni.

N. 5: ottimizza la connettività di rete

La maggior parte dei server aziendali di medio livello ora dispone di due NIC gigabit, ma la maggior parte di essi non utilizza la seconda pipe. Inoltre, i prezzi degli interruttori gigabit sono scesi a picco. Con un collegamento a 120 Mbps al tuo file server, un numero di client da 100 megabit può ottenere l'accesso ai file wire-rate simultaneamente.

Anche senza la commutazione gigabit, il legame NIC dovrebbe essere un punto fermo. Nella sua forma più semplice, l'unione di due NIC offre ridondanza, ma aggiungi il bilanciamento del carico di trasmissione e puoi raddoppiare efficacemente la larghezza di banda in uscita. L'utilizzo del teaming assistito da switch fornirà lo stesso effetto sul traffico in entrata. Quasi tutti i principali fornitori di server offrono driver per il teaming NIC e ci sono anche utilità di terze parti. È un aumento della larghezza di banda grande ed economico.

N. 6: Chiusura dei server Web

C'è davvero così tanto che puoi fare per ottimizzare un server Web e massimizzare le prestazioni? In effetti, c'è, principalmente regolando una manciata di impostazioni critiche per abbinare il traffico di produzione che ti aspetti.

Per i server Web già in produzione, iniziare raccogliendo le statistiche del server Web in tempo reale (la maggior parte dei principali server Web ha questa funzionalità incorporata). Quindi passare alla stadiazione per determinare quali parametri, se presenti, necessitano di regolazione.

Attivare gli strumenti di monitoraggio delle prestazioni del server Web sul server di staging. Eseguire un test di carico e ispezionare i parametri rilevanti, come il tempo di risposta, i byte inviati e ricevuti e il numero di richieste e risposte.

I parametri chiave da regolare in base al volume di traffico includono la memorizzazione nella cache, il threading e le impostazioni di connessione.

Abilita la memorizzazione nella cache per i contenuti utilizzati di frequente; alcuni server Web consentono di memorizzare i file nella cache in modo dinamico in base all'utilizzo, mentre altri richiedono di specificare cosa verrà memorizzato nella cache. Assicurati che la dimensione massima della cache sia sufficiente per il traffico previsto. E se il tuo server Web supporta l'accelerazione della cache, abilitala anche tu.

Per le impostazioni di threading e connessione, impostare i minimi e i massimi in base al carico di lavoro previsto. Per le connessioni, dovrai anche definire il numero massimo di richieste per connessione e l'impostazione del timeout della connessione. Non impostare nessuno di questi valori troppo piccolo o troppo grande, altrimenti potrebbero verificarsi rallentamenti.

N. 7: Il dolore della WAN

Pensi di dover recuperare la larghezza di banda WAN? Puoi facilmente spendere un pacchetto in appliance che modulano il traffico o motori di cache nel tentativo di frenare l'utilizzo della larghezza di banda WAN. Ma cosa succede se non è la pipa?

Per prima cosa: prima di acquistare qualsiasi cosa, fatti un'idea precisa del traffico che attraversa la WAN. Strumenti di analisi di rete come Ethereal, ntop, Network Instrument's Observer o WildPacket's EtherPeek NX possono darti una nuova visione di ciò che è realmente in gioco.

Potresti scoprire che i tempi di replica per Active Directory sono troppo bassi e la semplice configurazione di intervalli di replica più lunghi può farti guadagnare spazio durante la giornata lavorativa. Alcuni utenti in posizioni remote mappano le condivisioni sui server sbagliati e trasferiscono file di grandi dimensioni attraverso la WAN senza rendersene conto? Le vestigia di una rete IPX disabilitata da tempo sono ancora in circolazione? Alcuni problemi della WAN si riducono a un'errata configurazione dell'applicazione, in cui il traffico viene indirizzato attraverso la WAN quando avrebbe dovuto rimanere locale. Rapporti regolari sui modelli di traffico WAN faranno risparmiare denaro e mal di testa.

No. 8: Giochiamo bene

Troppo spesso, applicazioni, servizi Web e siti Web di più reparti dell'azienda competono per le risorse del server. Sebbene ciascuno di questi componenti possa essere ben regolato di per sé, un'applicazione di un altro reparto che utilizza anche gli stessi cluster di produzione potrebbe presentare una query non ottimizzata o qualche altro problema, che a sua volta influisce sugli utenti o sui clienti.

A breve termine, tutto ciò che puoi fare è lavorare con i tuoi amministratori di sistema e il reparto che sta riscontrando il problema di prestazioni per ottenere la risoluzione per i tuoi utenti o clienti. A lungo termine, crea una comunità in tutti i reparti che utilizzano i cluster di produzione in cui vengono distribuiti i tuoi oggetti. Lavorare tra i team per garantire che ci siano finanziamenti adeguati per un ambiente di staging che sia veramente rappresentativo dell'ambiente di produzione del carico di lavoro misto. Infine, ti consigliamo di sviluppare una serie di benchmark che possono essere utilizzati per convalidare le prestazioni del carico di lavoro misto nell'ambiente di staging.

N. 9: Caching, shaping, limitating, oh mio!

Se la tua WAN è veramente sottodimensionata e non puoi permetterti una rete frame relay a lungo raggio, il traffic shaping e il caching possono aiutare a sbloccare il pipe.

Le configurazioni che modellano il traffico sono più arte che scienza. La priorità delle app è spesso più politica che tecnica, ma può avere effetti enormi sulle prestazioni di rete percepite.

Il caching è una bestia completamente diversa. Richiede meno lavoro rispetto al traffic shaping, ma probabilmente l'impatto sarà minore. I motori di memorizzazione nella cache archiviano e forniscono copie locali dei dati a cui si accede comunemente per ridurre il traffico WAN. Lo svantaggio è che il contenuto dinamico non può essere veramente memorizzato nella cache, quindi la posta elettronica non godrà dello stesso aumento delle prestazioni.

N. 10: patch predittivo

Arrivi al lavoro lunedì solo per scoprire che un gruppo di desktop è bloccato o che le prestazioni di un'applicazione critica sono rallentate. Dopo aver esaminato, si determina che la causa è una patch applicata durante il fine settimana.

Ecco perché hai bisogno di strumenti che supportino i rollback delle patch. Ancora meglio, includi il test delle patch come parte della tua strategia di gestione delle patch. Innanzitutto, è necessario fare un inventario regolare delle applicazioni e delle tecnologie in gioco su desktop e server. La maggior parte degli strumenti di gestione dei sistemi, come gli SMS di Microsoft, hanno la capacità di fare l'inventario automaticamente.

Successivamente, replicare le applicazioni e le tecnologie in un ambiente di staging. Se il sistema operativo e il software dell'infrastruttura non includono strumenti di test delle patch, procurati uno strumento di terze parti come FLEXnet AdminStudio o Wise Package Studio.

In alternativa, puoi scrivere alcuni script per esercitare funzionalmente la piattaforma o la tecnologia con le ultime patch in gioco. Sarà necessario ripetere questo scenario (e modificare gli script) man mano che arrivano nuove patch e vengono apportate modifiche al software.