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.
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.
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:
|
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:
|
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. |