Sun Microsystems - Professional Services alberto.bianchi@sun

1(c) - copyright Sun Microsystems 19991

Misurazione prestazioni siti WEB Misurazione prestazioni siti WEB Misurazione prestazioni siti WEB Misurazione prestazioni siti WEB Misurazione prestazioni siti WEB Misurazione prestazioni siti WEB Misurazione prestazioni siti WEB Misurazione prestazioni siti WEB Misurazione prestazioni siti WEB Misurazione prestazioni siti WEB Una metodologia operativaUna metodologia operativaUna metodologia operativaUna metodologia operativaUna metodologia operativaUna metodologia operativaUna metodologia operativaUna metodologia operativaUna metodologia operativaUna metodologia operativa

Alberto BianchiAlberto BianchiAlberto BianchiAlberto BianchiAlberto BianchiAlberto BianchiAlberto BianchiAlberto BianchiAlberto BianchiAlberto BianchiSun Microsystems - Professional ServicesSun Microsystems - Professional ServicesSun Microsystems - Professional ServicesSun Microsystems - Professional ServicesSun Microsystems - Professional ServicesSun Microsystems - Professional ServicesSun Microsystems - Professional ServicesSun Microsystems - Professional ServicesSun Microsystems - Professional ServicesSun Microsystems - Professional [email protected]@[email protected]@[email protected]@[email protected]@[email protected]@sun.com

(c) - copyright Sun Microsystems 2000 2

Web Site Daily Internet commercerevenue as of 1/15/99

Lost revenue per hour ofdowntime as of 1/15/99*

www.techdata.com $1,000,000 $8,280

www.amazon.com $2,700,000 $22,500

www.dell.com $10,000,000 $91,320

www.cisco.com $20,000,000 $182,640

www.intel.com(partner extranet site only)

$33,000,000 $274,980

* Lost revenue assumes a $1 million-per-day site where 20% of transactions are lost during downtime. Costs due to brand erosion and decreased customer satisfaction are not included in these estimates

Forrester Research Inc. Jan. 1999


Good performance protects yourGood performance protects your revenue stream revenue stream

*Zona Research, 1999

le prestazioni di un sito Web hanno un impatto diretto sulle revenue dell'Azienda

"8 seconds rule" - 8 secondi e' il tempo oltre al quale un utente, in attesa di una pagina, abbandona il sito

piu' di 4 miliardi di Dollari in vendite associate a siti di e-commerce vengono persi ogni anno a causa di tempi di attesa troppo lunghi


85% of Sites Fail to scale past 25%

85% of Sites Fail to scale past 25%

of their expected usage

of their expected usage

- Findings from Mercury Interactive’s ActiveTest Service


il test di performance riduce i rischi di ridotta scalabilita'piu' della meta' delle applicazioni Web non scalano come previsto

“Failed to Scale”

No Test60%

Test Early6%

Test Late34%

“Scaled as Expected”

No Test6%

Test Late38%Test Early

56%


planning, allocazione budget, controllo capitale e spese:

"capitale" - risorse di calcolo fisse (RAM, spazio disco)

"spese" - risorse variabili, tempo di CPU, banda di rete

pianificazione per tempo delle risorse necessarie

monitoraggio risorse con sistemi di accounting

controllo risorse in base al carico

Analogia modello finanziarioAnalogia modello finanziario


raccolta dati di configurazione e performance

monitor allarme e visualizzazione in tempo reale

analisi in termini di business workload

previsione degli effetti di un cambiamento di carico

Performance mgmt: sequenzaPerformance mgmt: sequenza

Raccolta Monitor Analisi Previsionemetriche


controllo prestazioni

capacity planning

gestione livelli di servizio

attivazione tool di monitoring prestazionali e identificazione parametri critici.

definizione piano di monitoraggio costante per il tempo necessario.

definizione piano di coordinamento per correggere eventuali disservizi

obiettivo comune: massimizzare effettivo utilizzo risorse nel modo piu' efficace.

FunzioniFunzioni


3UREOHPDWLFD

- Name service misconf- NFS misconfiguration- Network bottlenecks- Obsolete patchlevlel- Undersized kernel parameters

- CPU busy- Slow disks- RAM shortage- Processes hogging CPU- Shortage of bandwith- High queue wait time- TCP/IP stack

6RODULV�UHIHUHQFH

- Init.conf- Resolv.conf- Sendmail.conf- /etc/system

- iostat, df, vmstat- sar, prex- netstat, nfstat- top, prsinfo- mpstat, ifstat- crash, truss

3DFNDJHV- SunExplorer- Patchdiag- Account

- SunExplorer- Memtool- Proctool- Perfmeter- SEToolkit- Teamquest

Static view Dynamic view

Performance analysis gridPerformance analysis grid


capacity planning: previsione di come e quando una architettura di sistemi puo' giungere a saturazione

tempi ridotti nel passaggio in produzione

prevenzione da possibili disservizi (malcontento degli utenti, diminuzione produttivita', vincoli economici e di budget)

scalabilita' dell'architettura

Capacity planningCapacity planning


quale tempo di risposta accettabile per l'applicazione

quanti utenti sono gestiti con quel tempo di risposta

scalabilita' dell'architettura

qual'e' il limite massimo di utenti gestibili

come raddoppiare la capacita'

come risponde il sistema al variare degli scenari

quali sono le parti piu' critiche o pesanti

Application testing checklistApplication testing checklist


199.254.35.100

WebServer

Load Balancer

Router

Router

Router

Router

Router

Database

App. Server

Vusers

Performance Monitors

previsione del comportamento "in produzione"identificazione e isolamento colli di bottiglia

199.201.181.37173.84.158.189168.171.48.153155.111.189.92………………...

Application stress testApplication stress test


test di application server, business logic e connettivita' sistemi di back-endstress dell'intera architettura con transazioni e dati realigarantire il testing applicativo con anticipo rispetto al passaggio in produzionetest di scalabilita' e verifica presenza colli di bottiglia a livello web, db server, application server o reteogni utente virtuale misura i tempi di risposta associati alle transazioniun controller raccoglie i dati prestazionali da client, rete e servers



App/Web Serve rApp/Web Server Database

Networ kNetwork

Virtual UsersVirtual Users

Controlle rController





Planning e preparazione: analisi ambiente applicativo e transazioni da testare, definizione ambiente di test minimale (sistemi, DB prova), definizione formato report, tempistica test (nel caso di ambienti in produzione).

Delivery: costruzione modello applicativo (workload) sull'ambiente di test, definizione parametri, definizione scenari multipli, predisposizione monitor risorse di sistema (bottleneck).

Closure: analisi report su applicazione e sistemi, considerazioni su utilizzo risorse, interventi applicativi e sistemistici, identificazione livelli di servizio.

Application test: metodologiaApplication test: metodologia


Web/App. ServerClient Network Back End Server

Software

Monitoring

Service Level ManagementService Level Management


monitor tempi risposta in produzione

SLM - dati reali e proattivi sull'effettivo andamento del sito

analisi di dettaglio sulle possibili cause di disservizio e attivazione opportuni allarmi

monitoring e diagnosi ai diversi livelli (presentation, application, backend)

Service Level ManagementService Level Management


3 tier arch: web, appl (Vignette), Oracle.

individuazione delle funzionalita' piu' critiche per l'applicazione in esame (sistema gia' in produzione)

definizione dei possibili casi reali

individuazione numero utenti virtuali eseguibili con un certo livello di servizio (100 utenti concorrenti eseguiti in 1 minuto)

verifica comportamento sistema all'aumentare del numero di utenti (capacity planning)

identificazione num. max utenti gestibili prima di saturare il sistema (crash test)

considerazioni su utilizzo risorse, identificazione problemi connessi al SW di base

CASE STUDY: Trading on lineCASE STUDY: Trading on line


CASE STUDY: Trading on lineCASE STUDY: Trading on line

individuazione, attraverso lo stress test, del numero massimo di utenti eseguibili con un certo livello di servizio (100 utenti concorrenti, Think Time = 0)verifica rapporto fra utenti potenziali (registrati) e utenti medi collegati (orari di picco) sul sito reale, es. 500/20000

calcolo quantita' di utenti supportabili con l'architettura esistente (100 simulati, 1000 collegati, 40000 abbonamenti secondo l'attuale tipologia di utenza)

verifica rapporto fra utenti reali e utenti simulati con lo stress test (1 a 10, TT=10 sec, 100 utenti simulati generano lo stesso carico di 1000 utenti reali)

verifica impatto firewall/bilanciatori


CASE STUDY: Portale di ricercaCASE STUDY: Portale di ricerca

3 tier arch: web, appl (ATG Dynamo), Oracle

sistema non in produzione

obiettivi:

individuazione tipologia di utilizzo del portale

individuazione throughput massimo erogabile (transazioni/sec)

definizione scenari multipli, calcolo intervalli di esecuzione, verifica utilizzo risorse sistema, calcolo transazioni nell'unita' di tempo

verifica impatto firewall/bilanciatori

Documents

Sun Microsystems - Professional Services alberto.bianchi@sun