WebSphere Extended Deployment, Version 6.0.x     Sistemi operativi: AIX, HP-UX, Linux, Solaris, Windows, z/OS

Configurazione dell'ARFW (autonomic request flow manager)

Anche se si tratta di un'operazione in genere non necessaria o non consigliata, è possibile ottimizzare il gestore autonomo del flusso di richieste (ARFM) modificando le impostazioni predefinite della console.

Motivi e situazioni in cui eseguire questa attività

Il gestore autonomo del flusso di richieste è composto da tre componenti: un profiler del lavoro, un controller e un gateway. La funzione ARFM viene implementata, per ciascun gruppo di nodi, da un profiler del lavoro e da un controller, ciascuno in esecuzione su un agente del nodo. Inoltre, una raccolta di gateway viene eseguita sui router on demand (ODR) per il traffico HTTP e sui server di backend per il traffico IIOP e JMS. I gateway intercettano e accodano le richieste HTTP e IIOP in entrata, mentre il controller fornisce i segnali di controllo, o direzioni, ai gateway e al controller di gestione. Il profiler del lavoro valuta continuamente i requisiti operativi dei diversi tipi di richieste, in base alle osservazioni del sistema in funzione. Lavorando in collaborazione, questi componenti sono in grado di assegnare la priorità alle richieste in entrata.

Per modificare le impostazioni predefinite di ARFM nella pagina della console di gestione, fare clic su Amministrazione di sistema > Gestori autonomi > Gestore autonomo del flusso di richieste.
NoteColonSymbol quando la sicurezza è abilitata, alcuni campi non risultano modificabili senza un'autorizzazione di sicurezza appropriata.
  1. Modificare le impostazioni di ARFM desiderate.
    Campo Utilizzato per Suggerimenti per l'impostazione
    Periodo di aggregazione Ciascun gateway di ARFM trasmette le statistiche aggregate periodicamente e questo parametro specifica l'intervallo di tempo in questione. Le statistiche notificate dal o dai gateway supportano:
    • La rappresentazione grafica del runtime nella console di gestione di WebSphere Extended Deployment.
    • Il funzionamento dei controller di ARFM.
    • Il funzionamento del controller di gestione delle applicazioni.
    • Il funzionamento dei profiler del lavoro.

    Quando viene impostato un periodo di aggregazione, assicurarsi che il valore sia sufficientemente grande da consentire la raccolta di un numero cospicuo di esempi di prestazioni. Gli esempi vengono raccolti dai gateway per ciascuna richiesta. Per produrre un'adeguata misurazione statistica, è necessario disporre di un centinaio di esempi.

    Utilizzo di un esempio - le richieste associate a una classe di servizio vengono eseguite in 250 millisecondi e, in media, vengono eseguite 10 richieste contemporaneamente. Il valore di simultaneità viene calcolato automaticamente da WebSphere Extended Deployment in base alla dimensione del cluster e alle risorse disponibili nell'ambiente. Tale valore viene riportato nei pannelli di visualizzazione, nella categoria Operazioni di runtime della console. Ne consegue che la classe di servizio è in grado di gestire circa 40 richieste al secondo. Per tale ragione, impostando il valore del periodo di aggregazione su 15 secondi verranno raccolti 600 esempi per ciascun periodo. Le metriche fornite da una ricerca su 600 esempi risultano estremamente utili e affidabili.

    Se il periodo di aggregazione viene impostato su un valore troppo basso, le metriche delle prestazioni risulteranno poco affidabili. Le metriche delle prestazioni risultanti da un numero esiguo di esempi sono molto confuse e poco affidabili rispetto a quelle che derivano da un numero di esempi maggiore. Poiché il controller ARFM risulta attivo durante la produzione di nuove statistiche, se il periodo di aggregazione viene impostato su un valore troppo alto si determina un rallentamento nella rielaborazione delle impostazioni di controllo. Come conseguenza, WebSphere Extended Deployment risponde meno velocemente alle modifiche improvvise dell'intensità di traffico e dei modelli.

    Lunghezza minima del ciclo di controllo Questo parametro definisce la frequenza con cui il controller ARFM viene attivato. L'attivazione del controller rappresenta un processo di valutazione degli input e di produzione di nuove impostazioni di controllo, come risultato degli input ricevuti. Tale processo di attivazione per un controller ARFM ha inizio quando vengono ricevute nuove statistiche da uno dei gateway E il tempo trascorso a partire dalla precedente attivazione risulta superiore o uguale alla lunghezza minima del ciclo di controllo oppure se il controller non è mai stato attivato prima. Questa impostazione determina l'assegnazione di un limite più basso della lunghezza del ciclo di controllo. Ad esempio, se si dispone soltanto di un ODR, il periodo di aggregazione viene impostato su 30 secondi e la lunghezza minima del ciclo di controllo viene impostata su 60 secondi, un'attivazione potrebbe verificarsi alle 12:00:00.0 e la successiva 90.1 secondi dopo, alle 12:01:30.1, poiché il tempo di arrivo delle statistiche precedente era 12:00:59.9. Per garantire un ciclo di controllo affidabile di circa 60 secondi, è opportuno impostare la lunghezza minima di tale ciclo su un valore pari a 58 o 59 secondi.
    Finestra arrotondamento Questa impostazione definisce la reattività del controller ARFM nei confronti delle statistiche del gateway in entrata, consentendo una concatenazione di tali statistiche. Per tutti i gateway, il controller ARFM utilizza la media dell'esecuzione degli ultimi report delle statistiche di quel determinato gateway. La finestra arrotondamento controlla il numero di report combinati.

    Un valore basso assegnato alla finestra arrotondamento rende il controller più sensibile e, di conseguenza, più reattivo. Tuttavia, un parametro basso determina anche una reattività maggiore alle anomalie dei dati.

    Si consiglia di mantenere una corrispondenza tra il valore indicato nella finestra arrotondamento e periodo di aggregazione, e la lunghezza effettiva del ciclo di controllo, che a volte risulta leggermente superiore rispetto alla lunghezza minima del ciclo di controllo.

    Lunghezza massima coda
    Questo parametro viene utilizzato per limitare la lunghezza di ogni coda di ARFM a un numero massimo di richieste che possono essere salvate nella coda. ARFM divide tutto il traffico in entrata in flussi, con una coda separata per ciascun flusso. Gli elementi del flusso comprendono richieste che:
    • Dispongono di una classe di servizio specifica.
    • Vengono supportate su una destinazione di distribuzione specifica.
    • Vengono instradate da un ODR specifico.
    Quando arriva una richiesta ma la relativa coda è piena, tale richiesta viene rifiutata.
    Un parametro basso di questo campo aumenta la possibilità che una richiesta venga rifiutata a causa della quantità di traffico a breve termine, mentre un parametro più alto consente alle richieste di rimanere più a lungo in sospeso nelle code. Le richieste accodate utilizzano memoria. L'impostazione predefinita è 1000, ma è possibile modificare questa impostazione per rilevare il valore che meglio si adatta all'ambiente in uso.
    Uso massimo della CPU

    ARFM fornisce protezione da sovraccarico, oltre a funzioni di assegnazione di priorità. Per evitare il sovraccarico dei server delle applicazioni, ARFM accoda le richieste nei gateway.

    Per questa release, il carico viene determinato in termini di uso della CPU sul primo livello dei server delle applicazioni. Il parametro relativo all'uso massimo della CPU indica a ARFM la quantità massima di lavoro da caricare nei server. In condizioni di picco massimo, il limite impostato può essere superato per brevi periodi di tempo.

    Valori maggiori consentono un utilizzo migliore delle risorse, mentre valori inferiori determinano un funzionamento più stabile. Il carico effettivo è estremamente variabile e incerto. Le tecnologie di gestione delle prestazioni di WebSphere Extended Deployment reagiscono alle variazioni di carico, ma in leggero ritardo. Durante il periodo di reazione, il sistema può operare al di fuori della propria regione configurata; ne consegue un uso maggiore della CPU rispetto a quello impostato. È stato osservato che, se un server delle applicazioni viene fatto funzionare utilizzando la CPU al 100% per diversi minuti, si verifica l'interruzione di alcuni meccanismi interni di comunicazione con conseguente riduzione di numerose funzioni.

    È opportuno che questa impostazione corrisponda all'impostazione seguente relativa all'utilizzo della CPU di destinazione stimato con velocità normale. Se viene modificata una impostazione, è consigliabile modificare anche l'altra. Il valore predefinito per ognuna è pari a 90 (percento).

    La gestione delle prestazioni in questa release di WebSphere Extended Deployment non funziona in modo ottimale se il primo livello delle macchine dei server delle applicazioni vengono caricate con ulteriore lavoro rispetto alle richieste WebSphere trasmesse via HTTP tramite gli ODR.

    Questa impostazione influenza la gestione delle applicazioni. Se la domanda totale prevista supera il limite massimo di utilizzo della CPU, il controller di gestione riduce uniformemente la domanda di tutti i cluster dinamici prima di calcolare la gestione migliore.

  2. Fare clic su OK o Applica una volta terminato.
  3. Verificare di aver salvato le modifiche nel repository principale, facendo clic su Salva.
  4. Verificare le impostazioni appena definite e ripetere il procedimento fino a ottenere le prestazioni desiderate per il flusso di richieste.



Related tasks
Configurazione dei fattori di velocità in configurazioni a più livelli

Argomento Attività    

Termini di utilizzo | Commenti Ultimo aggiornamento: Mar 20, 2006 1:05:58 PM EST
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=?topic=/com.ibm.websphere.xd.doc/info/odoe_task/todtunearfm.html

© Copyright IBM 2004, 2006. Tutti i diritti riservati.
Questo centro informazioni utilizza la tecnologia Eclipse. (http://www.eclipse.org)