Test di carico sostenibile
Le informazioni contenute in questo argomento si riferiscono ai test illustrati in Scenari di test per la misurazione dell'MST del motore.
Per il primo test, il sistema è stato portato alla velocità effettiva massima sostenibile (MST, Maximum Sustainable Throughput) per consentire di eseguire osservazioni di un sistema integro.
Nel grafico seguente sono riportati gli indicatori chiave dopo l'utilizzo di questo approccio per individuare la velocità effettiva massima sostenibile del sistema di test.
Profilo di carico di un test di carico sostenibile
In questo grafico viene mostrato che, per l'ora del test, la profondità dello spooler era stabile e non in aumento:
Le linee nere nella parte superiore del grafico mostrano i messaggi totali ricevuti ogni secondo dal sistema, ad esempio per entrambi i server di ricezione.
Le linee nella parte inferiore del grafico indicano la profondità dello spooler MessageBox in ogni SQL Server.
Dopo che il sistema è stato portato al punto di profondità di spooler stabile massima, la MST viene misurata dal numero di messaggi ricevuti al secondo. Per questo scenario, nell'hardware descritto, è stata raggiunta una MST di 290 messaggi al secondo.
Nota
Quando il sistema viene portato a un punto in cui la profondità di spooler non è più stabile nel tempo, significa che la MST è stata superata. Possono essere richiesti diversi test con carico variabile per valutare il carico massimo al quale la profondità di spooler rimane stabile e il sistema è in grado di gestire il backlog dei messaggi senza incorrere in un ulteriore backlog dei messaggi.
Parte di qualsiasi analisi delle prestazioni di una distribuzione BizTalk dovrebbe includere il controllo di alcuni indicatori chiave per capire i colli di bottiglia delle risorse. Le misure chiave e i loro valori utilizzati per questa distribuzione in esecuzione alla velocità effettiva massima sostenibile sono stati i seguenti:
Utilizzo CPU
| Server | Utilizzo CPU medio |
|---|---|
| Server BizTalk | 55% |
| SQL Server (server MessageBox master) | 76% |
| SQL Server (altri server MessageBox) | 83% |
Tempo di inattività del disco fisico
| Server | Tempo di inattività medio del disco |
|---|---|
| Media per tutti gli SQL Server | 69% |
Blocchi SQL su SQL Server
| Parametro | Valore |
|---|---|
| Timeout di blocco totale medio al secondo (per SQL Server) | 1980 |
| Tempo di attesa medio blocco totale (ms) | 495 |
Durante questo test non sono stati generati errori nel registro applicazioni BizTalk o SQL Server.
Da questi dati è possibile trarre le seguenti conclusioni:
Nel sistema non esistono colli di bottiglia evidenti delle risorse.
Tutti questi indicatori rientrano perfettamente nei limiti di integrità.
I tempi di inattività di CPU e disco mostrano che lo spazio è più che sufficiente e che non si avvicina neppure al pegging.
Gli indicatori di blocco SQL hanno un aspetto ottimale, i timeout di blocco/sec non iniziano a diventare un problema fino a circa 5000 (a seconda della SQL Server) e i tempi di attesa blocco al di sotto di 1 secondo sono integri.
Dopo aver illustrato come trovare la velocità effettiva massima sostenibile e aver visto come si presentano gli indicatori chiave per un sistema integro e sostenibile, verranno esaminati alcuni comportamenti associati a un sistema che riceve più rapidamente di quanto sia in grado di elaborare ed eseguire le procedure di garbage collection. Passare a Test di carico overdrive.
Vedere anche
Scenari di test per misurare la velocità effettiva massima sostenibile del motore
Test di superamento del limite di carico