Milano, 23 Ottobre 2009 Conferenza stampa di presentazione della 45esima Esposizione Prevedere Internazionale le di Information prestazioni & Communications dei sistemi Technology web con il patrocinio di: Segnali dal futuro. ed evitare gli abbandoni degli utenti Pierantonio Macola Amministratore Delegato Smau Giuseppe Galli APM senior specialist 1
Obiettivo Presentare il metodo di certificazione delle capacità di un sistema. Il metodo, ideato da K-Tech, è basato sulle discipline SPE/APM. Si certifica la capacità dei sistemi in produzione per controllare le performance e prevedere il comportamento in presenza di un carico stimato. Il metodo può essere applicato sia con l'ausilio di software commerciale, sia con software open source. 2
Relatore Ing. Giuseppe Galli CV Partner in K-Tech, CTO Esperto in APM da 4 anni Lavoro su soluzioni Java nel dominio enterprise dal 1998 In K-Tech da 7 anni g.galli@k-tech.it Collabora con Javaportal.it 3
L'azienda: K-Tech s.r.l. Dove il nostro Know how ci ha portato Siamo una società romana che opera a 360 sulla tecnologia Java in ambito Enterprise. Competenze in: Application Performance Management Software Performance Engineering Project Management System Administration OOAD Formazione Oracle IBM CA Wily -.. Open Source Servizi in EMEA: MCS, CRC, Business Continuity 24X7 on site < 24h from call Certificati ISO 9001 in Progettazione ed erogazione di corsi di formazione 4
Target e Motivazioni del Talk Il target: I Manager delle operation Gli architetti delle soluzioni software I responsabili delle linee di business (LOB Owner) Aspiranti Software Performance Engineer Le motivazioni: Condividere la nostra esperienza in un contesto di professionisti e accademici. 5
Necessità del cliente: performance Servizi on-line con alta visibilità (siti istituzionali..) Servizi on-line critici per il business ( e-banking, e- commerce..) Servizi interni (email, LDAP, intranet, ) Rispetto SLA / Requisiti non funzionali tempi di risposta medi (on-line) 'finestre' temporali (batch) 99.9999% di affidabilità Costi di manutenzione Dimensionamento ottimale delle architetture 6
Performance: definizione E' l'insieme dei requisiti (impliciti ed espliciti) non funzionali che caratterizzano la qualità del software come percepita dall'utente. La qualità del sistema preposto all'erogazione del servizio che indica quanto bene esso assolva lo scopo per cui è stato costruito. 7
Processo di certificazione Cliente + Applicazione + Metodo SPE + Strumenti APM + Esperienza Certificazione: Garantire la capacità di una applicazione prevedendo come si comporterà in produzione sotto un certo carico stimato. 8
SPE - Software Performance Engineering Le performance sono curate con la giusta attenzione durante il ciclo di vita del software, a partire dalla progettazione della soluzione e del disegno del software. E' un metodo quantitativo che fornisce le basi teoriche e gli strumenti conoscitivi per identificare i problemi architetturali e di design, e quantificare i costi delle modifiche. 9
APM Application Performance Management Per la gestione delle performance applicative si utilizzano degli indicatori quali tempi di risposta, disponibilità del servizio, capacità del sistema, utilizzo delle risorse HW, throughput, carico, etc etc Con strumenti opportuni si monitora il sistema di produzione per anticipare i problemi tramite avvisi e implementare processi ITIL per il service management (ITSM) come l'incident Management (IcM). In Pre-produzione/QA/Test si utilizzano i dati di performance per riprodurre i problemi. 10
Processo APM: gli attori coinvolti Developer Help Desk DBA LOB Manager Sysadmin 11
Architettura di produzione Web Servers AS Front-end AS Back-end Load balancer Internet Sistema distribuito Sistema complesso Scalabilità Alta Affidabilità Database/Storage/EIS 12
Monitoraggio: Complex System Web Servers AS Front-end AS Back-end Load balancer Internet Database/Storage/EIS 13
Ambiente di Load Test Web Servers AS Front-end AS Back-end Load balancer Database/Storage/EIS 14
Certificazione: ruoli e strumenti Analista: studia i pattern di utilizzo del sistema utilizzando strumenti statistici, file di log, etc. SPE Engineer: ha la conoscenza di cosa fare durante la certificazione APM Specialist: conosce il metodo e gli strumenti per il monitoraggio DBA, System Administrator, Architect: presenti presso il cliente Ogni figura ha il proprio set di strumenti specifico, i dati di performance sono condivisi tra i gruppi. 15
Certificazione: definizione degli obiettivi Espressi in funzione delle aspettative Esempi: N utenti connessi / h Processi eseguiti parallelamente Tempi di risposta (medi/massimi/percentili) Pagine servite / h Sono metriche (condivise e concordate) indicative della qualità del servizio apprezzata dal cliente. 16
Certificazione: le iterazioni del ciclo Analisi degli obiettivi Presentazione risultati Configurazione tuning de monitoraggio Analisi dei dati dei test Implementazione/esecuzione dei test 17
Certificazione: analisi del sistema Cosa? Dati statistici di accesso all'applicazione Traffico di rete Dati provenienti dal monitoraggio dei componenti applicativi Perché? La distribuzione temporale del carico sull'applicazione Funzionalità più utilizzate Eventi critici 18
Certificazione: indicatori primari e di dettaglio Tempi di risposta Invocazioni concorrenti Invocazioni per secondo Invocazioni andate a buon fine Numero di azioni nella stessa transazione Risorse in uso Latenza di rete 19
Certificazione: i test Progettazione Identificazione degli use case critici Creazione dei test case, schedulazioni e script di automazione Esecuzione Test successivi con carico crescente Monitoraggio e registrazione risultati Validazione Stima dell'errore Ripetibilità dei test 20
Load Test: identificazione KPI La definizione dei principali indicatori delle performance avviene nella fase di load test. Si emula una situazione di traffico potenzialmente pericolosa per il servizio. Throughput dei componenti (Servlet,Web Services,... ) Response Time (EJB, SQL,...) Risorse Usate (CPU, Memoria, Banda...) 21
Certificazione: risultato 22
Certificazione: validazione dei risultati Gli esiti della certificazione devono essere compatibili con le osservazioni registrate in produzione Il documento finale: Certifica i limiti di capacità del sistema Descrive dettagliatamente le azioni fatte Elenca con le priorità le azioni da effettuare Quantifica i miglioramenti possibili Giustifica le conclusioni ottenute 23
Certificazione: risultati tipici Batch Identificazione dei colli di bottiglia Determinazione del livello di parallelismo minimo On-line Determinazione delle risorse minime necessarie (dimensione del cluster, numero di connessione al DB) Identificazione dei componenti problematici Impatto disattenzione Best Practice 24
Generazione mensile della fattura elettronica Scenario: Contratti da fatturare aumentano di un ordine di grandezza. L'hardware a disposizione è stato maggiorato. Le performance del batch permettono di rispettare la finestra temporale a disposizione? Stabiliti gli obiettivi di performance (KPI): fatture/ora Punto di partenza: 16 giorni Monitorati e individuati i colli di bottiglia: Opencursor su mainframe, attività query (No. commit, tempi di esecuzione, No. invocazioni), logging, ecc.. Definito il parallelismo minimo necessario. Tempi: 2 settimane (elapsed) Risultato finale: 5 ore Successo: Previsti con precisione i tempi del batch in produzione. 25
National utility web site Scenario: Picchi di carico massimo ad opera degli utenti, crash all'aumentare delle richieste, sistema instabile. L'hardware a disposizione è stato potenziato. Punto di partenza: 10.218 unique browser/h, 124.000 page views/h Obiettivo: Architettura che permetta un throughput doppio rispetto al limite attuale. Individuata una migliore configurazione per il deployment FE BE., cambiamento architetturale degli Application Server, aumentata la cache sul FE, determinate le modifiche da effettuare sul codice, documentati i moduli 'problematici' Tempi: 3 settimane (elapsed) Punto di arrivo: 7 Gennaio, 18.000 unique browser/h e 207.000 page view/h Successo: registrato l'uso 273 Gb di banda giornalieri (record contro i 109 precedenti) 26
National utility web site Throughput: Situazione Iniziale 124.000 page views/h 10.000 unique browser/h Pagine Visualizzate Utenti 140000 12000 120000 10000 100000 8000 80000 60000 10/12/07 6000 10/12/07 40000 4000 20000 2000 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 27
National utility web site Throughput: Situazione Finale 207.000 page views/h 18.000 unique browser/h Pagine Visualizzate Utenti 250000 18000 200000 16000 14000 150000 100000 07/01/09 12000 10000 8000 6000 07/01/09 50000 0 1 3 5 7 9 11 13 15 17 19 21 23 4000 2000 0 1 3 5 7 9 11 13 15 17 19 21 23 28
National utility web site 124.000 => 207.000 page views/h 10.000 =>18.000 unique browser/h 29
APM: Strumenti Monitoraggio: Introscope CA Wily Dynatrace FogLight Quest JXInsight JInspired ITCAM & Tivoli IBM OpenView HP Awstats Nagios Load Test: JMeter Grinder Load Runner 30
Ringraziamenti Un ringraziamento a tutto il personale K-Tech: /.*/@k-tech.it Ed in particolare a: Mara Marzocchi, Simone Federici e Serafina Rocca 31
Riferimenti http://www.k-tech.it http://www.javaportal.it http://www.perfeng.com/ http://en.wikipedia.org/wiki/complex_system/ http://www.systems-thinking.org/ http://www.itil-officialsite.com/ ITIL By OGC http://www.ca.com/us/application-management-solution.aspx Connie U. Smith (1990), Performance Engineering of Software Systems, 1 st Edition Connie U. Smith & Lloyd G. Williams (2005), Performance Solutions: A Practical Guide to Creating Responsive, Scalable Software (Addison-Wesley Object Technology Series) 32
Q/A 33