Corso di Laurea Specialistica in Ingegneria Informatica
Definizione e validazione sperimentale di regole di
scrittura del codice per ottimizzare l’efficienza
energetica del software
Relatore: Prof.ssa Chiara FRANCALANCI
Correlatori: Prof. Eugenio CAPRA
Ing. Marco BESSI
Tesi di Laurea di: Marco LUI, matricola 719975
Ringraziamenti
Desidero in primo luogo ringraziare tutte le persone che mi hanno aiutato allo svolgimento di questo lavoro di tesi.
Un sentito ringraziamento alla Prof.ssa Chiara Francalanci che mi ha dato l’opportunità di svolgere questo lavoro molto interessante e per le utilissime (e divertenti!) lezioni dei suoi corsi.
Un grandissimo ringraziamento anche al Prof. Eugenio Capra e all’Ing. Marco Bessi per avermi costantemente seguito, aiutato e consigliato in tutto il lungo percorso della tesi.
Rimanendo in ambito Politecnico vorrei ringraziare tutti i miei compagni di corso ed amici, in particolar modo Dario e Davide (mitticci!), che mi hanno accompagnato in tutta (o quasi tutta) questa avventura. E che belli i nostri progetti!
Un ringraziamento a tutti gli amici, vicini e lontani che mi hanno supportato in questi anni e con cui ho passato momenti divertenti e spensierati.
Un grazie speciale alle mie due famiglie, che mi hanno sempre sostenuto ed incoraggiato (e sfamato!).
Infine un ringraziamento particolare a Jasmine, che mi ha costantemente incitato e rincuorato. Sei stata la stella che mi ha guidato! Grazie di tutto.
4
Abstract
Nel corso degli ultimi anni i dispositivi tecnologici ed i sistemi informatici si sono molto sviluppati e diventati ormai di uso comune. Questa enorme crescita porta con sé anche alcune problematiche ambientali relative ai consumi energetici diretti ed indiretti (per esempio per gli impianti di condizionamento dei data center), con un conseguente impatto sull’inquinamento terrestre. Per questo motivo è nata una nuova disciplina che si occupa di queste problematiche, ovvero il Green IT.
Questo lavoro di tesi rientra nell’ambito di un filone particolare del Green IT, ovvero il Green Software, che si occupa di massimizzare l’efficienza energetica del software. Questo filone risulta ancora poco esplorato in quanto gli sforzi maggiori si sono concentrati soprattutto sul miglioramento dell’efficienza dell’hardware.
Il lavoro di tesi si è concentrato sulla ricerca di regole metodologiche in grado di aumentare l’efficienza energetica del software scritto in linguaggio Java. In particolare sono stati eseguiti diversi test riguardanti la gestione delle stringhe, l’utilizzo degli iteratori e il costrutto switch.
Sono stati creati dei piccoli programmi contenenti i costrutti obiettivo dell’analisi e le loro versioni alternative, con l’apporto di alcune modifiche. I test hanno permesso di confrontare i tempi di esecuzione di tutte le versioni e quindi di estrapolare alcune regole per la programmazione di applicativi Java in grado di massimizzare l’efficienza energetica. Si è trovato ad esempio che l’utilizzo di uno switch al posto di alcuni if concatenati fra loro (almeno 3) permette di risparmiare fino al 70% sul tempo di esecuzione. Oppure l’utilizzo di un oggetto StringBuilder per il concatenamento tra stringhe permette di risparmiare il 50% rispetto al classico metodo con il simbolo”+”.
5
Le regole trovate non hanno un valore assoluto, ma dipendono sempre da alcune condizioni. Per esempio si è trovato che un iteratore che esamina gli oggetti contenuti in un vettore risulta più efficiente di un semplice ciclo (risparmio dal 15% al 65%), ma solo se il vettore contiene un certo numero di oggetti.
Dato che un risparmio sul tempo di esecuzione non si traduce necessariamente in un risparmio energetico è stato necessario eseguire dei test energetici in laboratorio per la validazione delle regole. Come applicativo esempio è stato scelto Adempiere, un programma ERP Open Source.
Sono stati ripetuti i test misurando il consumo energetico effettivo mediante un’apposita strumentazione e questi hanno permesso di confermare la bontà delle regole trovate. I test energetici su un piccolo programma ad hoc implementato seguendo tutte le regole di ottimizzazione trovate ha permesso una riduzione del tempo di esecuzione del 65% ed un risparmio energetico vicino all’80%.
6
Indice
Elenco delle Figure 9
Elenco delle Tabelle 11
1 Introduzione 13
2 Stato dell’arte 15
2.1 Introduzione al Green IT 15
2.2 Green Software 22
3 Metodologia 24
3.1 Introduzione alla metodologia 24
3.2 Fase 1: Scelta ed analisi dell’applicativo da testare 25
3.2.1 Analisi programmi ERP 25
3.2.2 Struttura di Adempiere 26
3.3 Fase 2: Ricerca di classi e metodi significativi 38
3.3.1 JProf 38
3.3.2 Test and Performance Tools Platform (TPTP) 38
3.3.3 Scelta metodi per i test 41
3.4 Fase 3: Testing 42
3.4.1 Test su if concatenati e switch 42
3.4.2 Test sugli iteratori 47
3.4.3 Test sulle stringhe: StringBuilder e StringBuffer 50
7
3.4.5 Test sulle stringhe: concatenamento 61
3.4.6 Test sulle stringhe: metodi generici 63
3.4.7 Test finale: programma ad hoc 65
3.5 Fase 4: Analisi risultati e stesura regole 73
3.6 Fase 5: Test energetici 74
3.6.1 Strumentazione 74
3.6.2 Preparazione ed esecuzione dei test 78
4 Risultati e regole di ottimizzazione 81
4.1 Risultati test su if concatenati e switch 82
4.1.1 If - switch a 7 scelte 82
4.1.2 If - switch con meno di 7 scelte 84
4.1.3 If - switch con più cicli 87
4.1.4 Cicli for - while 89
4.2 Risultati test sugli iteratori 90
4.2.1 Iteratori con numero valutazioni variabili 90
4.3 Risultati test sulle stringhe 93
4.3.1 Metodo Convert 93
4.3.2 Metodo Substring 95
4.3.3 Metodo Substring con diverse dimensioni sottostringa 97
4.3.4 Concatenamento di stringhe 101
4.3.5 Concatenamento di stringhe con attributi statici 102
4.3.6 Risultati test sui metodi generici 104
4.4 Risultati test programma ad hoc 107
4.5 Regole di ottimizzazione 109
5 Validazione empirica dei risultati 112
8
5.2 Validazione programma ad hoc 116
5.3 Stima risparmio energetico 118
5.3.1 Stima risparmio energetico if - switch 118
5.3.2 Stima risparmio energetico concatenamenti di stringhe 120
5.3.3 Stima risparmio energetico sul test ad hoc 123
6 Conclusione e sviluppi futuri 125
9
Elenco delle Figure
Figura 2.1 - Andamento annuale dei costi delle infrastrutture IT.
Fonte: IDC (2006) ... 17
Figura 2.2 - Rapporto tra spesa per energia e raffreddamento / spese per nuovi server (%). Fonte: IDC (2006) ... 18
Figura 3.1 - Diagramma Application Server ... 27
Figura 3.2 - Diagramma Client Applicativo ... 28
Figura 3.3 - Diagramma Gestione Database ... 28
Figura 3.4 - Diagramma Interfaccia Grafica ... 29
Figura 3.5 - Risultati di un'esecuzione esempio visualizzati con TPTP ... 40
Figura 3.6 - Class Diagram del programma usato per il test su if concatenati ... 44
Figura 3.7 - Gerarchia stringhe utilizzate nel metodo convert... 57
Figura 3.8 - System Board ... 75
Figura 3.9 - NI USB-6210 DAQ ... 76
Figura 3.10 - Interfaccia del programma di acquisizione dati in LabVIEW ... 77
Figura 3.11 - Schema dei collegamenti del sistema di acquisizione dati... 77
Figura 4.1 - Grafico Base Time metodi load e load2 (a 7 scelte) ... 83
Figura 4.2 - Grafico Cumulative Time metodi load e load2 (a 7 scelte) ... 84
Figura 4.3 - Grafico andamento Base Time in base al numero di if / case ... 86
Figura 4.4 - Grafico andamento Cumulative Time in base al numero di if / case ... 86
Figura 4.5 - Grafico andamento Base Time in base al numero di POInfoColumn .... 88
Figura 4.6 - Grafico Andamento Cumulative Time in base al numero di POInfoColumn ... 88
Figura 4.7 - Grafico Base Time metodo load con e senza iteratori ... 91
Figura 4.8 - Grafico Base Time metodo load con e senza iteratori (zoom) ... 91
10
Figura 4.10 - Grafico Cumulative Time metodo load con e senza iteratori (zoom) .. 92
Figura 4.11 - Grafico Base Time metodi convert ... 94
Figura 4.12 - Grafico Cumulative Time metodi convert ... 94
Figura 4.13 - Grafico Base Time metodi sub ... 96
Figura 4.14 - Grafico Cumulative Time metodi sub ... 96
Figura 4.15 - Grafico Base Time metodi sub in base alla lunghezza sottostringa ... 99
Figura 4.16 - Grafico Base Time solo primi 3 metodi sub in base alla lunghezza sottostringa... 99
Figura 4.17 - Grafico Cumulative Time metodi sub in base alla lunghezza sottostringa... 100
Figura 4.18 - Grafico Cumulative Time solo primi 3 metodi sub in base alla lunghezza sottostringa ... 100
Figura 4.19 - Grafico Base Time metodi concatenamento stringhe ... 101
Figura 4.20 - Grafico Cumulative Time metodi concatenamento stringhe ... 102
Figura 4.21 - Grafico Base Time metodi concatenamento con attributi statici ... 103
Figura 4.22 - Grafico Cumulative Time metodi concatenamento con attributi statici ... 103
Figura 4.23 - Grafico Base Time metodo charAt ... 104
Figura 4.24 - Grafico Cumulative Time metodo charAt ... 105
Figura 4.25 - Grafico Base Time metodo getChars ... 106
Figura 4.26 - Grafico Cumulative Time metodo getChars ... 106
Figura 4.27 - Grafico Cumulative e CPU Time metodi load ... 108
Figura 4.28 - Grafico Cumulative e CPU Time globali ... 108
Figura 5.1 - Grafico tempo effettivo if/switch ... 114
Figura 5.2 - Grafico energia effettiva if/switch ... 114
Figura 5.3 - Grafico andamento Potenze istantanee nel tempo ... 115
Figura 5.4 - Grafico tempo effettivo programma ad hoc ... 116
Figura 5.5 - Grafico energia effettiva programma ad hoc ... 117
11
Elenco delle Tabelle
Tabella 3.1 - Packages contenuti nella cartella base/src ... 29
Tabella 3.2 - Packages contenuti nella cartella glassfishfacet/src ... 32
Tabella 3.3 - Packages contenuti nella cartella jbossfacet/src ... 33
Tabella 3.4 - Packages contenuti nella cartella client/src ... 33
Tabella 3.5 - Packages contenuti nella cartella sqlj/src ... 34
Tabella 3.6 - Packages contenuti nella cartella install/src ... 34
Tabella 3.7 - Packages contenuti nella cartella Extend/src ... 35
Tabella 3.8 - Packages contenuti nella cartella serverRoot/src/main/ejb ... 35
Tabella 3.9 - Packages contenuti nella cartella serverRoot/src/main/server... 35
Tabella 3.10 - Packages contenuti nella cartella serverRoot/src/main/servlet ... 35
Tabella 3.11 - Packages contenuti nella cartella serverApps/src/main/servlet ... 36
Tabella 3.12 - Packages contenuti nella cartella zkwebui/WEB-INF/src ... 36
Tabella 3.13 - Packages contenuti nella cartella JasperReports/src ... 36
Tabella 3.14 - Packages contenuti nella cartella JasperReportsWebApp/src ... 36
Tabella 3.15 - Packages contenuti nella cartella tools/src ... 36
Tabella 3.16 - Packages contenuti nella cartella webCM/src/main/servlet ... 37
Tabella 3.17 - Packages contenuti nella cartella migration/src... 37
Tabella 3.18 - Packages contenuti nella cartella posterita/posterita/src/main ... 38
Tabella 3.19 - Elenco metodi più significativi ... 41
Tabella 3.20 - Dati di esempio per il calcolo della confidenza ... 46
Tabella 3.21 - Mappa valori tra ColumnClass e ClassInt ... 73
Tabella 4.1 - Risultati test if - switch a 7 scelte ... 82
Tabella 4.2 - Tempi di esecuzione metodi chiamati da load ... 82
Tabella 4.3 - Tempi di esecuzione metodi chiamati da load2 ... 83
Tabella 4.4 - Tempi di esecuzione if/switch con meno di 7 scelte ... 85
Tabella 4.5 - Tempi di esecuzione in base al numero di POInfoColumn ... 87
Tabella 4.6 - Tempi di esecuzione test for / while ... 89
12
Tabella 4.8 - Tempi di esecuzione metodi convert ... 93
Tabella 4.9 - Tempi di esecuzione metodi sub ... 95
Tabella 4.10 - Tempi di esecuzione metodi sub in base alla lunghezza della sottostringa ... 98
Tabella 4.11 - Tempi di esecuzione metodi concatenamento ... 101
Tabella 4.12 – Tempi di esecuzione metodi concatenamento con attributi statici .. 102
Tabella 4.13 - Tempi di esecuzione metodo charAt ... 104
Tabella 4.14 - Tempi di esecuzione metodo getChars ... 105
Tabella 4.15 - Tempi di esecuzione metodo load e loadMod ... 107
Tabella 4.16 - Tempi di esecuzione MainAsIs e MainMod ... 108
Tabella 4.17 - Riassunto regole di ottimizzazione energetica ... 111
Tabella 5.1 - Dati test energetico su if/switch ... 113
Tabella 5.2 - Dati test energetico programma ad hoc ... 116
Tabella 5.3 - Risparmio if/switch nelle classi del package org.compiere.apps ... 119
Tabella 5.4 - Risparmio if/switch nelle classi del package org.compiere.model ... 119
Tabella 5.5 - Risparmi totali su if/switch ... 120
Tabella 5.6 - Risparmio concatenamenti stringhe nelle classi del package org.compiere.apps ... 120
Tabella 5.7 - Risparmio concatenamenti stringhe nelle classi del package org.compiere.model ... 121
Tabella 5.8 - Risparmi totali sui concatenamenti ... 122
Tabella 5.9 - Risparmio programma ad hoc ... 123
13
Capitolo 1
1
Introduzione
Negli ultimi anni i sistemi IT si sono enormemente sviluppati e diffusi, con conseguente aumento della richiesta di energia per il loro mantenimento. Questa maggior richiesta di energia porta con sé ulteriori problematiche:
Aumento considerevole del costo del mantenimento dei sistemi IT, dovuto anche al costante aumento del prezzo dell’energia.
Difficoltà nella scalabilità per i grandi sistemi, in quanto la fornitura di così grandi quantità di energia non sempre è possibile.
Incremento dell’impatto ambientale dovuto al consumo di energia.
Queste problematiche hanno portato alla nascita e allo sviluppo di un nuovo campo di ricerca, il Green IT.
Gli studi in questo nuovo campo si sono però principalmente concentrati sul miglioramento dell’efficienza dei dispositivi hardware e sulla loro gestione logistica, mentre l’aspetto software è stato preso poco in considerazione.
In realtà anche il software può giocare una parte importante per il miglioramento energetico, in quanto gestisce e comanda l’hardware. La maggior efficienza hardware potrebbe essere amplificata ulteriormente da un miglioramento della gestione dei dispositivi, soprattutto degli elementi più critici, come la CPU.
Questo lavoro di tesi si pone all’interno dell’ambito ancora poco studiato dell’efficienza energetica del software applicativo, cercando di fornire regole per la
14
programmazione energeticamente efficiente in linguaggio Java. Queste regole sono state validate in maniera sperimentale eseguendo delle misurazioni energetiche in laboratorio. I risultati ottenuti hanno confermato sperimentalmente la bontà delle regole elaborate.
Nel Capitolo 2 vengono introdotti i concetti principali e le problematiche riguardanti il risparmio energetico. Viene descritto l’impatto attuale e futuro del settore IT sia da un punto di vista ambientale che economico. Verrà illustrato infine lo stato attuale della ricerca sul software efficiente.
Nel Capitolo 3 viene descritta la metodologia seguita per questo lavoro di tesi, mettendo in evidenza le varie fasi. Per ogni fase vengono descritti la procedura e gli strumenti utilizzati.
Nel Capitolo 4 sono mostrati tutti i risultati ottenuti dai test su programmi esempio per la valutazione dei tempi di esecuzione di alcuni costrutti particolari e le possibili soluzioni per il miglioramento delle prestazioni. Verranno infine redatte alcune regole per la programmazione efficiente.
Nel Capitolo 5 viene descritta la procedura sperimentale di validazione delle regole elaborate, effettuata tramite misurazioni energetiche (mediante un’apposita strumentazione) di alcune esecuzioni di programmi ad hoc. Dai dati energetici si è potuto confermare l’utilità delle regole di efficienza. Viene inoltre fornito un metodo per stimare il risparmio energetico prodotto dalle migliorie trovate.
15
Capitolo 2
2
Stato dell’arte
In questo capitolo viene descritto lo stato attuale della ricerca sul risparmio energetico nel campo dell’Information Technology.
Nel paragrafo 2.1 vengono introdotte le problematiche relative al Green IT, con la descrizione dei campi di studio e lo stato attuale della ricerca.
Nel paragrafo 2.2 si prende in considerazione maggiormente un aspetto specifico, ovvero quello del Green Software, con le relative problematiche e gli sviluppi futuri.
2.1 Introduzione al Green IT
I sistemi informatici ed i dispositivi tecnologici sono ormai diventati parte integrante della nostra vita. Data la loro enorme diffusione e l’intenso utilizzo, questi sistemi hanno un impatto ambientale considerevole, che non può più essere ignorato.
Secondo recenti studi [1, 2, 3] il settore IT produce il 2% delle emissioni globali di CO2, con un impatto equivalente a quello dell’industria aeronautica. Le previsioni per il 2020 indicano addirittura un aumento di questa quantità fino al 6% [2].
C’è da notare però che l’IT può avere un ruolo importantissimo nel monitorare ed ottimizzare il restante 98%, quello che viene chiamato IT for a greener business. I sistemi IT possono diventare fondamentali per il controllo di tutti i processi di business.
16
L’impatto ambientale dell’IT è costituito sia dai sistemi aziendali che dall’IT distribuito, come per esempio PC, monitor, stampanti, laptop. Basti pensare che un singolo computer genera 1 tonnellata di CO2 all’anno [4] ed un Pentium IV dissipa 120 W, a fronte di soli 10 W di un 486. Questa richiesta di potenza si ha in quanto i processori si sono notevolmente evoluti, aumentando prestazioni e diminuendo le dimensioni, ma conseguentemente richiedendo più energia per la dissipazione del calore.
I prodotti dell’IT distribuito sono interessanti in quanto il loro campo di applicazione è molto vasto. Si parla infatti non solo dei prodotti acquistati da singoli privati, ma anche quelli utilizzati all’interno degli uffici di qualsiasi azienda, società o pubblica amministrazione, ovvero qualsiasi luogo che dispone di postazioni di lavoro informatizzate. Nonostante ciò le leve principali che spingono verso l’ottimizzazione sono più di tipo gestionale che informatico.
Parlando invece di IT aziendale, ci si può fare un’idea dei consumi energetici pensando che un moderno server blade consuma 1 kW, paragonabile al consumo di un normale frigorifero. Un rack di server blade (con 5 scaffali di 8 unità ciascuno) consuma 40 kW, cioè quanto una palazzina. Un data center di medie dimensioni può consumare anche 300 kW, l’equivalente di 100 appartamenti, mentre grandi data center di grosse banche o di internet service provider possono consumare diversi MW, come un piccola cittadina. È quindi evidente che le riduzioni di consumo e di costo sono rilevanti, anche se riguardano un numero abbastanza ristretto di aziende (in Italia sono circa 3 mila i data center con più di 5 rack). [5, 6]
La maggior parte del consumo di energia deriva dai componenti infrastrutturali, ovvero impianti di condizionamento, gli UPS (Uninterruptible Power Supply) e i sistemi di distribuzione dell’energia. [7, 8]
Come si vede in Figura 2.1, negli anni tra il 1996 ed il 2010 il costo dell’hardware (in blu scuro) è cresciuto meno rispetto a quello dell’energia e del raffreddamento (in verde).
17
Figura 2.1 - Andamento annuale dei costi delle infrastrutture IT. Fonte: IDC (2006)
Il costo di energia e raffreddamento rappresenta il 60% della spesa in nuove infrastrutture, come evidenziato nella Figura 2.2. C’è da tenere in considerazione anche il fatto che questi valori sono ottenuti da analisi a livello mondiale, dove il costo dell’energia è più basso rispetto all’Italia (per esempio il costo dell’energia a livello industriale è poco sotto i 7 $cent/kWh negli Stati Uniti, mentre in Italia è di quasi 26 $cent/kWh [9] ), ed evidenziano ancora di più l’importanza di ridurre il consumo energetico nel nostro paese.
18
Figura 2.2 - Rapporto tra spesa per energia e raffreddamento / spese per nuovi server (%). Fonte: IDC (2006)
La crescita considerevole dei consumi energetici dell’IT sta attirando quindi l’attenzione della comunità scientifica, dei produttori di tecnologia e dei responsabili del settore IT. Da queste basi sorge il Green IT, ovvero un’informatica ecologicamente sostenibile. Il Green IT si occupa dello studio e dell’attuazione di tecniche di progettazione e realizzazione di computer, server, sistemi connessi e sistemi di comunicazione efficienti, con impatti ambientali ridotti. [1]
Le tematiche principali che studia possono essere riferite a queste tre:
Miglioramento dell’efficienza energetica dell’IT.
Gestione eco-compatibile del ciclo di vita di tutti gli apparati dell’IT.
Utilizzo dell’IT come strumento di governance green.
La prima area ha l’obiettivo di migliorare la progettazione dell’architettura dei sistemi informativi e dei data center, in modo da ottimizzare il consumo energetico. Vengono presi in considerazione diversi aspetti di questi ambiti, come la virtualizzazione, la scelta oculata dei server, il ripensamento del layout dei data center, l’ottimizzazione degli impianti di condizionamento, ma agendo anche sulle abitudini di utilizzo e modificando la cultura aziendale.
19
La seconda area riguarda l’impatto ambientale del ciclo di vita dei componenti IT ed il loro smaltimento. Vengono presi in considerazioni aspetti che vanno dalla produzione dell’hardware limitando l’uso di sostanze pericolose, all’ottimizzazione degli imballaggi e alla rottamazione dei prodotti non più utilizzabili. I “rifiuti di apparecchiature elettriche ed elettroniche” (RAEE), chiamati anche “Waste of Electric and Electronic Equipment” (WEEE), o più semplicemente “e-waste”, sono rifiuti particolari derivanti da qualsiasi apparecchiatura elettrica od elettronica. Tali rifiuti contengono sostanze tossiche ed è quindi molto importante controllare la loro dismissione, in modo da non costituire pericolo per l’ambiente. Secondo alcune recenti ricerche [3] il 70% dell’inquinamento del suolo da piombo, cadmio e mercurio deriva direttamente o indirettamente dall’IT. Sono quindi state introdotte diverse norme per la regolazione dello smaltimento di questi rifiuti in recepimento di alcune direttive Europee. [10]
La terza area ha l’obiettivo di utilizzare le tecnologie IT per il monitoraggio e la misurazione del grado di eco sostenibilità di ogni processo aziendale ed industriale, non quindi necessariamente connesso con l’IT. Si parla per esempio di controllo sul consumo energetico, sulle temperature, sull’utilizzo di materiali come carta ed accessori, sulla produzione di rifiuti tossici. Questo monitoraggio può essere effettuato definendo dei nuovi Key Performance Indicator (KPI) “green” portandoli all’attenzione dei manager. I KPI possono essere memorizzati ed analizzati tramite cruscotti direzionali e di business intelligence. [5]
Data la vastità del campo di ricerca del Green IT, l’approccio sicuramente migliore per massimizzare l’efficienza energetica (soprattutto per le aziende) è quello multi-livello. È importante infatti agire contemporaneamente su diversi aspetti del sistema informatico e non solo su quello che incide di più sul consumo. Da un articolo di Francalanci e Capra [5] viene qui ripreso un esempio riguardante un data center: i livelli su cui si può agire sono numerosi.
A livello di infrastruttura i punti più critici sono quelli dei gruppi di continuità ed i sistemi di condizionamento. Nel caso questi ultimi fossero a potenza fissa, si potrebbe pensare di sostituirli con altri in grado di modulare il raffreddamento a
20
seconda del luogo e delle necessità. Inoltre le disposizioni degli scaffali e delle bocchette di condizionamento dovrebbero essere studiati con cura.
A livello di sistema si possono ottenere enormi risparmi bilanciando correttamente i carichi di lavoro sui server ed utilizzando la virtualizzazione.
Analizzando i singoli server si possono trovare diversi punti critici, come la gestione delle periferiche e dei componenti ausiliari. Modulare la velocità delle ventole in base alle necessità è un esempio molto semplice e pratico per ridurre i consumi, oppure utilizzare meno drive ma più potenti. Questi accorgimenti possono portare a riduzioni fino al 50% dei consumi. Un’altra grande fonte di spreco è la conversione dell’energia da alternata a continua per ogni singolo server, che può essere ottimizzata centralizzandola in un unico dispositivo per più macchine. Questa soluzione richiede però che i macchinari siano predisposti e necessita di collaborazione da parte dei produttori hardware. Infine anche una migliore gestione della distribuzione dell’energia ad alcune componenti del sistema, come la cache, può portare notevoli vantaggi, alimentando solo le parti in quel momento utilizzate. Un altro punto critico con notevoli inefficienze è il processore, ben lontano dalle massime prestazioni possibili. Spesso inoltre non funzionano al massimo delle loro capacità e non vengono sfruttati in maniera efficiente. L’abbassamento della frequenza di clock e l’utilizzo di più core possono ridurre i consumi fino al 50% [1]. A livello di rete si potrebbe ottenere una maggiore efficienza ripensando gli algoritmi di routing tenendo in considerazione anche gli aspetti energetici, oltre ad utilizzare hardware più efficiente.
In un certo modo anche i database possono influenzare negativamente l’efficienza energetica. Infatti se i dati sono di scarsa qualità (duplicati, non aggiornati, inconsistenti) richiedono più transazioni ed operazioni per la correzione ed il loro reperimento, aumentando quindi i consumi.
Chiaramente anche il software gioca un ruolo fondamentale, ma verrà discusso nel dettaglio nel paragrafo successivo.
21
Infine non si deve assolutamente trascurare che le pratiche di utilizzo possono essere causa di notevoli inefficienze. Alcune ricerche hanno dimostrato che un corretto uso delle funzioni di power management, l’uso intelligente di screen saver e la buona abitudine di spegnere i sistemi quando non utilizzati, possono portare ad un risparmio del 60% dei consumi. [11] Oltre a queste vi sono numerose altre azioni da fare per ridurre gli sprechi, come per esempio effettuare stampe fronte-retro, riparmiando carta ed energia.
In generale è necessario un cambiamento culturale aziendale e degli utenti. L’ intera azienda dovrebbe cominciare a tenere in considerazione l’aspetto green nella progettazione, manutenzione e gestione di tutti i sistemi, sia per l’aspetto ambientale, sia per l’aspetto economica che ne deriva.
A livello nazionale ed internazionale cominciano ad aumentare le iniziative e gli accordi per la progressiva diminuzione dei consumi energetici e dell’inquinamento che ne deriva, proponendo anche incentivi per la ricerca ed il risparmio.
La Comunità Europea ha sviluppato diverse normative volte ad incentivare il risparmio energetico, soprattutto in ambito industriale (direttive 2001/77/CE, 2005/32/CE, 2006/32/CE). [12]
Come non citare inoltre il famoso protocollo di Kyoto sottostritto nel 1997 nell’ambito della Convenzione quadro delle Nazioi Unite sui Cambiamenti Climatici (UNFCCC).
Recentemente negli Stati Uniti sono stati varati pacchetti ecomici, noti come American Recovery and Reinvestment Act (ARRA), che riguardavano anche l’efficienza energetica e la ricerca nelle energie rinnovabili (27.2 Miliardi di dollari). [13]
22
2.2 Green Software
I responsabili del consumo di energia sono fisicamente i dispositivi hardware, ma questi sono necessariamente guidati dal software, che è quindi il responsabile primo (non fisico) e che determina quali operazioni devono essere eseguite e come. Il
Green Software è la disciplina che studia le modalità con cui il software influenza i
consumi energetici dell’IT, cercando nuovi modi per ottimizzarlo. [6]
Questo aspetto di solito viene poco preso in considerazione, in quanto si pensa che il software abbia un’influenza ridotta sui consumi, riconducibile solamente al processore, che di per sé non è la fonte principale di consumo. Infatti i maggiori sforzi fatti finora nell’ambito del Green IT si sono concentrati sull’hardware e sulle strutture. Questo però è un approccio limitato, in quanto se il software è più efficiente e riesce a svolgere le stesse funzioni con meno operazioni ed in meno tempo, si avranno vantaggi a cascata anche sulle altre componenti, in quanto sarà prodotto meno calore, con un calo del fabbisogno energetico per il condizionamento. Finora i principali studi di low power software si sono concentrati sui sistemi embedded. In questo caso però la leva principale non era il risparmio energetico rivolto ad un minor impatto ecologico, ma indirizzato alla limitazione di consumo della batteria, vero limite dei dispositivi mobili.
In generale però il classico ciclo di sviluppo di un software non prende mai in considerazione l’efficienza energetica come uno degli obiettivi, come invece lo sono costi, funzionalità e performance.
Uno dei problemi principali che si trovano nell’ambito dell’ottimizzazione del software è sicuramente la ricerca di un metodo per misurare l’efficienza energetica, soprattutto la definizione di una metrica. Infatti l’efficienza va valutata come consumo in base alla quantità di lavoro svolta e quindi molto dipendente dalle condizioni del sistema e dal carico di lavoro. Oltretutto risulta anche difficile scorporare il consumo relativo al software dal consumo generale del sistema.
L’obiettivo di migliorare l’efficienza energetica del software può essere raggiunto principalmente mediante due approcci. Un primo approccio è quello dell’ottimizzazione a livello di sistema, indipendente quindi dal tipo di codice
23
utilizzato. La ricerca in questo campo è molto aperta e spesso si focalizza sulla scelta oculata dello stack, dato che l’interazione tra sistema operativo e applicazione ha un impatto sul consumo considerevole.
Il secondo approccio è quello invece relativo all’ottimizzazione del codice. Chiaramente un codice ben scritto può avere notevole influenza sulle performance energetiche del programma. Ma questo approccio può portare ad ulteriori benefici, come lo sviluppo di metodologie, linee guida e tool per lo sviluppo di software efficiente. Il lavoro di questa tesi si pone proprio all’interno di questo ambito, cercando di elaborare linee guida utili per lo sviluppo di software energeticamente efficiente.
Non sempre però questo tipo di approccio è utilizzabile (in caso di software non prodotto in proprio) e utile: non è pensabile per esempio analizzare ed ottimizzare tutto il codice di un sistema bancario e se anche ci si riuscisse probabilmente lo sforzo difficilmente verrebbe ripagato dai risparmi ottenuti.
24
Capitolo 3
3
Metodologia
3.1 Introduzione alla metodologia
In questo capitolo verrà mostrata la metodologia che è stata seguita per lo svolgimento del lavoro di tesi. Verranno descritte le diverse fasi, gli strumenti utilizzati e il metodo di analisi dei dati raccolti.
Le fasi principali descritte in seguito possono essere così riassunte:
1. Scelta ed analisi dell’applicativo da testare: sono elencati i programmi presi in considerazione e l’analisi approfondita dell’applicativo scelto.
2. Ricerca di classi e metodi significativi: sono descritti gli strumenti utilizzati per la ricerca delle classi e dei metodi con maggior impatto sui tempi di esecuzione.
3. Testing: sono descritti i test effettuati per la valutazione dei tempi di esecuzione dei programmi con e senza le modifiche per il miglioramento dell’efficienza, suddivisi per categorie.
4. Analisi dei risultati: sono riportati i dati ottenuti nei test, con la loro analisi e la stesura di regole per la programmazione efficiente.
5. Test Energetici: sono descritti i test energetici effettuati per la validazione dei risultati ottenuti in precedenza, gli strumenti necessari per le rilevazioni energetiche e la metodologia utilizzata.
25
3.2 Fase 1: Scelta ed analisi dell’applicativo da testare
3.2.1 Analisi programmi ERP
Per prima cosa è stato svolto un lavoro esplorativo sulle applicazioni disponibili e più adatte allo scopo. Come avvenuto in lavori precedenti, per esempio quello di Formenti e Gallazzi [14] e quello di Alberio e Brianza [15], sono stati analizzati alcuni programmi ERP (Enterprise Resource Planning). Questi programmi permettono di integrare i processi di business rilevanti per un’azienda, come le vendite, gli acquisti, il marketing, la contabilità, la gestione magazzino ecc … [16] Sono stati scelti questi programmi in quanto utilizzati nelle aziende, che potrebbero essere i soggetti più interessati ad un risparmio energetico, e quindi economico. La peculiarità di questi programmi è che sono tipicamente suddivisi in moduli, ognuno con le proprie funzionalità, ma in grado di comunicare con gli altri moduli. La scelta dei moduli dipende dalle esigenze e dalle caratteristiche dell’azienda. Tra i componenti principali possiamo trovare:
Contabilità
Controllo di gestione
Gestione del personale
Gestione Acquisti
Gestione dei magazzini
Material Requirements Planning - Pianificazione del fabbisogno dei materiali.
Gestione della produzione
Gestione Progetti
Gestione Vendite
Gestione della Distribuzione
Gestione della manutenzione impianti
26
L’analisi si è concentrata però su prodotti dedicati ad aziende di medie-piccole dimensioni e che propongono una soluzione all-in-one, ovvero un solo programma con tutte le funzionalità più importanti.
Sono stati analizzati 3 programmi ERP:
Adempiere
OpenBravo
OpenERP
La caratteristica comune a tutti è che sono programmi Open Source. Questa caratteristica si è resa fondamentale per poter esplorare senza problemi il codice sorgente ed esaminare a fondo struttura e funzionalità di questi programmi.
Dopo aver analizzato questi programmi si è deciso di concentrarsi su Adempiere, in quanto è stato ritenuto più semplice da utilizzare ed adatto allo scopo. Il programma è scritto in linguaggio Java e permette di default l’utilizzo del database PostgreSQL, anch’esso Open Source. La versione a cui si farà sempre riferimento è la 3.6.
Una volta scelto il programma ne è seguita un’analisi statica, in modo da capirne la struttura e le funzionalità.
3.2.2 Struttura di Adempiere
La struttura è abbastanza complessa; infatti il codice del programma è suddiviso in 19 package e più di 4.000 classi Java.
Vi è la possibilità di utilizzare il programma sia installando un client sul proprio PC che sfruttando l’interfaccia web messa a disposizione. Nel secondo caso è necessario quindi un application server con cui fare il deploy dell’applicazione. I comandi e le funzionalità sono comunque gli stessi in entrambe le modalità di funzionamento. Di default sono consentiti due Application Server differenti: JBoss e Glassfish. È possibile però aggiungere altri tipi di server implementando correttamente le interfacce corrispondenti. Nello specifico è presente un’interfaccia IApplicationServer che rappresenta il generico Application Server. Le classi
27
specifiche di ogni tipologia di Server devono necessariamente implementare quell’interfaccia. La classe ASFactory contiene un elenco aggiornato delle istanze di Application Server disponibili.
Nel nostro caso però non è stato necessario utilizzare l’interfaccia web e quindi si è preferito eseguire i test con un client applicativo installato su PC.
Figura 3.1 - Diagramma Application Server
Adempiere prevede la possibilità di un applicativo da installare sulla macchina client. La parte grafica viene gestita dalle classi contenute nei package org.compiere.apps (e apps.form, search e wf), org.compiere.grid, org.compiere.minigrid.
28
Figura 3.2 - Diagramma Client Applicativo
Anche per quanto riguarda il Database di appoggio sono presenti in Adempiere due possibilità di default: PostgreSQL e Oracle. La scelta è ricaduta su PostegreSQL, un database Open Source. È sempre possibile comunque aggiungere la compatibilità con altri database implementando le interfacce che gestiscono i database. In questo caso è presente l’interfaccia AdempiereDatabase che deve essere implementata dalle classi dei singoli DB, come DB_Oracle e DB_PostgeSQL. Esiste poi una classe Database che mantiene l’elenco dei Database disponibili.
29
Aggiungere il supporto ad un nuovo tipo di Database implica anche il fatto di dover implementare una classe che permetta la conversione dei comandi SQL standard nel linguaggio target del database, basandosi su una classe astratta Convert.
I package che si occupano di definire la veste grafica del programma sono org.compiere.swing (che opera una ridefinizione delle classiche swing), org.ademiere.plaf (che gestisce il look&feel), org. compiere.plaf.
Figura 3.4 - Diagramma Interfaccia Grafica
L’interfaccia grafica costituisce una parte decisamente importante per quanto riguarda i consumi ed il tempo di esecuzione. Questa incisività ha comportato diversi problemi nella fase di raccolta dei dati che verrà spiegata successivamente.
Per completezza verrà riportato ora l’elenco di tutti package che compongono il codice di Adempiere, con una breve descrizione di ognuno di essi.
Tabella 3.1 - Packages contenuti nella cartella base/src
Package Descrizione
com.akunagroup.uk.postcode Contiene interfacce e classi per il servizio web di ricerca di codice postale.
org.adempiere.apps.graph Si occupa della creazione e gestione dei grafici.
30
installato (jboss o glassfish).
org.adempiere.common Contiene una classe che inserisce in una mappa valore-chiave i nomi di alcune classi utilizzate nel client con le rispettive classi del client web.
org.adempiere.exceptions Raccoglie tutte le classi che definiscono le eccezioni.
org.adempiere.impexp Gestisce l’esportazione di dati in file xls. org.adempiere.model Si occupa della gestione del modello (bean,
tabelle, oggetti persistenti …).
org.adempiere.pdf Genera report in formato pdf.
org.adempiere.pdf.viewer Visualizzatore pdf che usa jpedal.
org.adempiere.pipo Contiene interfaccia e classi per l’import -
export di file xml e conversioni in xml.
org.adempiere.pipo.exception Contiene classi che estendono runtime exception.
org.adempiere.pipo.handler Contiene tutte le classi che estendono o lavorano con le classi di pipo per la conversione xml.
org.adempiere.plaf Gestione del look and feel. Vengono ridefiniti button, label, combo box ecc … delle rispettive swing.
org.adempiere.print.export Implementa l’interfaccia per l’esportazione
in file xls in org.adempiere.impexp.
org.adempiere.process Classi che estendono
org.compiere.process.SvrProcess. Generano campi ASP e gestiscono ordini RMA.
org.adempiere.process.rpl Contiene un’interfaccia per l’import export e
una classe di utility per XML.
org.adempiere.process.rpl.exp Contiene classi per l’esportazione. org.adempiere.process.rpl.imp Contiene classi per l’importazione.
org.adempiere.util Package che raccoglie classi che forniscono utility di vario genere. In particolare presenta classi che permettono di creare
31
nuovi modelli di classe e un’interfaccia per effettuare ricerche di campi nel database.
org.compiere Contiene la classe Adempiere per lo startup del sistema.
org.compiere.acct Gestione dei record pubblicati.
org.compiere.cm Contiene una classe per il controllo del deploy del web project e qualche utility di gestione stringhe.
org.compiere.db Package per la gestione dei database.
org.compiere.dbPort Contiene le classi per la conversione di comandi SQL da Oracle ad altri database.
org.compiere.impexp Contiene classi per l’import di modelli e
formati.
org.compiere.interfaces Presenta l’interfaccia per il server adempiere
(executeTask, dbProcess, createEmail, workflow…) e per lo Stato del db (principalmente getter).
org.compiere.model Contiene diverse interfacce per le tabelle dei database. Queste interfacce vengono implementate dalle relative classi, le quali estendono la classe PO.
org.compiere.plaf Pluggable Look&Feel UI.
org.compiere.print Gestione stampa.
org.compiere.print.layout Gestione stampa del layout.
org.compiere.process Fornisce i processi utilizzati a livello Server (e opzionalmente a livello Client). A runtime viene controllata la presenza del Server. Se esiste le classi vengono invocate via Application Server, altrimenti localmente.
Sono presenti molte classi importanti, principalmente per: gestire account, adempiere server e service, allocazione processi, gestione BP, crittazione colonne,
32
copia oggetti, gestione ordini, colonne ecc …
org.compiere.report Contiene le classi dei modelli di report per colonne, linee, alberi e report finanziari.
org.compiere.report.core Contiene le classi per creare i report.
org.compiere.sla Criteri, misurazioni e Goal del Service Level Agreement.
org.compiere.swing Fornisce le componenti swing per l’interfaccia di Adempiere.
org.compiere.tools Fornisce utility per i file (processamento, sostituzione stringhe, latex), testing RMI e conversione file testo Windows in Linux.
org.compiere.util Package che contiene diverse utility, come la gestione degli errori di configurazione, traduzione di numeri in parole nelle varie lingue, processi asincroni, gestione cache, gestione logger, gestione DB, gestione System Enviroment, traduzioni del login, gestione login, Sicurezza.
org.compiere.wf Modelli di workflow e loro gestione.
org.eevolution.model Contiene numerose interfacce generate e modelli generati che le implementano.
org.eevolution.process Contiene qualche classe per il trasferimento bancario, creazione di formati di esportazione da una finestra, calcolo tasse sugli ordini.
org.globalqss.process Permette di creare report del Cash Flow e la gestione del Cash Plan.
Tabella 3.2 - Packages contenuti nella cartella glassfishfacet/src
Package Descrizione
org.adempiere.as.glassfish Contiene la classe Glassfish che implementa org.adempiere.as.IApplicationServer (in base/src) e un modulo per la login.
33
Tabella 3.3 - Packages contenuti nella cartella jbossfacet/src
Package Descrizione
org.adempiere.as.jboss Contiene la classe JBoss che implementa org.adempiere.as.IApplicationServer (in base/src) e un modulo per la login.
Tabella 3.4 - Packages contenuti nella cartella client/src
Package Descrizione
de.schaeffer.compiere.tools Contiene una classe che implementa l’interfaccia AbstractDocumentSearch in org.adempiere.util (base/src) per la ricerca e l’apertura di finestre per transazioni definite.
org.adempiere.apps.graph Contiene classi per la gestione dei grafici e le relative utility, lato client, e la visualizzazione degli Indicatori di Performance.
org.compiere.acct Gestione Account Viewer e relativi dati.
org.compiere.apps Contiene classi che implementano componenti dell’interfaccia utente di alto livello del client applicativo. Per esempio il menù delle finestre. Contiene anche le conversioni nelle varie lingue del login. Permette anche di allegare file.
org.compiere.apps.form Raccoglie modelli di form personalizzati.
org.compiere.apps.search Classi che implementano la ricerca, visualizzazione info, lookup. La ricerca viene effettuata su diversi oggetti: operazioni cash, asset, BP, Ordini, Invoice …
org.compiere.apps.wf Classi per l’interfaccia utente del workflow
(layout, pannello, icone …).
org.compiere.grid Implementa datagrid, application dialog personalizzati e tabpane per le finestre
34
dell’applicazione.
org.compiere.grid.ed Gestisce alcuni elementi dell’ambiente
grafico, come finestre, calendario, pannelli …
org.compiere.grid.tree Creazione di un modello ad albero, basandosi su MTree (org.compiere.model).
org.compiere.install Gestione e importazione delle traduzioni.
org.compiere.minigrid JTable personalizzate nelle form dell’applicazione client.
org.compiere.pos Point Of Sale per il PC terminale.
org.compiere.print Controller dei report e della stampa.
org.eevolution.form Contiene una classe per la gestione manuale delle spedizioni.
Tabella 3.5 - Packages contenuti nella cartella sqlj/src
Package Descrizione
org.compiere.sqlj Contiene le classi per le query con sqlj. I metodi sono suddivisi a seconda dell’oggetto a cui si riferiscono: Account, BPartner, Currency, Invoice, Payment, Product…
Tabella 3.6 - Packages contenuti nella cartella install/src
Package Descrizione
org.compiere.install Contiene l’interfaccia Config e le classi che
la implementano. Queste classi servono per la configurazione durante l’installazione di JBoss, Glassfish, DB Oracle, DB PostgreSQL, JVM, Open e Apple JVM, e le classi per le traduzioni nelle varie lingue delle finestre di setup.
35
Tabella 3.7 - Packages contenuti nella cartella Extend/src
Package Descrizione
compiere.model Esempi di modelli.
org.compiere.test; test; test.functional; test.functional.inventory;
test.performance
Packages che contengono solo classi di test.
Tabella 3.8 - Packages contenuti nella cartella serverRoot/src/main/ejb
Package Descrizione
org.compiere.session Package che contiene diverse classi per la gestione dei Java Beans.
Tabella 3.9 - Packages contenuti nella cartella serverRoot/src/main/server
Package Descrizione
org.adempiere.server.rpl; org.adempiere.server.rpl.impl
Packages che contengono interfaccia e implementazione del processo per l’importazione.
org.compiere.ldap Gestione delle connessione ldap e decodifica dei messaggi.
org.compiere.server Contiene la classe AdempiereServer e AdempiereServerMgr come manager del server. Presenta poi delle classi Processor per l’Account, Alert, Email, Replication, Request, Workflow, le quali estendono la classe AdempiereServer.
Tabella 3.10 - Packages contenuti nella cartella serverRoot/src/main/servlet
Package Descrizione
36
Tabella 3.11 - Packages contenuti nella cartella serverApps/src/main/servlet
Package Descrizione
org.compiere.wstore Contiene servlet.
org.compiere.www Contiene servlet.
Tabella 3.12 - Packages contenuti nella cartella zkwebui/WEB-INF/src
Package Descrizione
org.adempiere.webui Gestione dell’interfaccia grafica web.
Ci sono diversi altri package, che ricalcano la classificazione del client, ma per il servizio web (es: apps, form, graph, grid, install, util …)
Tabella 3.13 - Packages contenuti nella cartella JasperReports/src
Package Descrizione
org.compiere.report Contiene le classi per la creazione dei report tramite le librerie Jasper Report.
org.compiere.utils Contiene una classe per il digest dei file.
Tabella 3.14 - Packages contenuti nella cartella JasperReportsWebApp/src
Package Descrizione
org.compiere.ejb Bean per l’hash MD5. org.compiere.interfaces Interfaccia MD5.
org.compiere.utils Test per MD5.
org.compiere.web Servlet per ottenere l’MD5.
Tabella 3.15 - Packages contenuti nella cartella tools/src
Package Descrizione
org.apache.ecs Classi che permettono di creare codice di markup (come html) tramite oggetti java.
37
org.apache.ecs.filter Classi per creare filtri.
org.apache.ecs.storage Definisce un oggetto di tipo Array, con tutti i metodi per gestirlo.
org.apache.ecs.xhtml Contiene diverse classi. Ognuna si occupa di creare un tipo di tag html.
org.apache.xml Contiene classi per la creazione di documenti xml e la creazione di generici tag.
Tabella 3.16 - Packages contenuti nella cartella webCM/src/main/servlet
Package Descrizione
og.compiere.cm Ridefinisce una HttpServlet con la possibilità di salvare qualche global enviroment e cache. Definisce poi alcune singole servlet.
og.compiere.cm.extend Contiene una classe che cerca l’indice del
risultato.
org.compiere.cm.cache Gestione della cache nel web server per ridurre il carico del DB e velocizzare il caricamento delle pagine.
org.compiere.cm.request Contiene una classe per creare o aggiornare Requests.
org.compiere.cm.utils Qualche classe aggiuntiva per le servlet.
og.compiere.cm.xml Generazione di xslt.
Tabella 3.17 - Packages contenuti nella cartella migration/src
Package Descrizione
oracle Permette la migrazione da un database oracle ad un altro.
38
Tabella 3.18 - Packages contenuti nella cartella posterita/posterita/src/main
Package Descrizione
Diversi package Contiene tutte le classi per la gestione POS tramite Posterita.
3.3 Fase 2: Ricerca di classi e metodi significativi
Una volta chiarita la struttura del programma si è cercato di individuare le classi e i metodi Java con un’influenza maggiore sul tempo di esecuzione.
Per farlo sono stati utilizzati dei software Java Profiler, ovvero JProf e TPTP.
3.3.1 JProf
JProf è un software sviluppato da IBM che permette di ottenere diverse informazioni sull’esecuzione di un programma Java.
Nello specifico è in grado di raccogliere tutte le informazioni riguardanti le chiamate dei metodi e dei relativi tempi di esecuzione.
Questo software è stato utilizzato durante un’esecuzione tipica del programma Adempiere, che prevedeva azioni comuni come l’inserimento di un nuovo Business Partner, la ricerca di un prodotto, l’inserimento di un nuovo ordine ecc …
I risultati vengono poi inseriti in un semplice file di testo con l’elenco cronologico dei metodi chiamati. Questo output si è rivelato però molto difficile da esaminare e gestire, soprattutto considerando le dimensioni del programma Adempiere. Per questo motivo le successive analisi che richiedevano un maggior dettaglio sono state eseguite con un altro tool, ovvero TPTP.
3.3.2 Test and Performance Tools Platform (TPTP)
39
Eclipse propone un ambiente di sviluppo multi linguaggio e multi piattaforma, che ha un suo punto di forza nella possibilità di aumentare le funzionalità tramite plug-in. TPTP è infatti un plug-in che può essere installato sia scaricandolo individualmente dal sito del progetto che tramite un update manager interno alla piattaforma Eclipse. La versione di Eclipse utilizzata nei test è la 3.6, chiamata Helios, mentre la versione di TPTP è la 4.7.2. Esiste una versione più recente della piattaforma, chiamata Indigo, ma non supporta più TPTP, in quanto la 4.7.2 è l’ultima versione rilasciata prima della chiusura del progetto.
Dato l’utilizzo della versione 3.6 di Eclipse si è utilizzata la versione 6 di Java, in quanto l’ultima versione 7 non viene supportata.
Il tool TPTP permette di raccogliere informazioni importanti sull’esecuzione di un programma java lanciato direttamente da Eclipse. In particolare vengono registrati per ogni metodo:
Base Time: tempo di esecuzione netto del metodo, tenendo conto di tutte le volte che questo viene chiamato;
Average Base Time: tempo medio di esecuzione del metodo, calcolato come Base Time diviso il numero di chiamate del metodo;
Cumulative Time: simile al Base Time, ma considera anche il tempo di esecuzione dei vari metodi che possono essere chiamati. Coincide praticamente con il tempo intercorso tra la chiamata e la conclusione del metodo, comprendendo tutto quello che viene fatto all’interno;
Cumulative CPU Time: tempo durante il quale la CPU è occupata nell’esecuzione del metodo;
Calls: numero di chiamate del metodo.
Questi valori sono poi consultabili raggruppati per classe e per package. Vengono inoltre forniti tutti i dati come percentuale rispetto al tempo totale di esecuzione.
40
Una caratteristica molto utile è la possibilità di applicare dei filtri in modo da eliminare dall’analisi determinati metodi, classi o package che non vengono ritenuti interessanti.
Questo tool ha permesso di eseguire direttamente in Eclipse il programma Adempiere e tutti i casi test ed avere direttamente i dati sulle esecuzioni, senza bisogno di ulteriori programmi esterni. È possibile poi esportare tali dati in report in formato tabulare csv o html.
41
3.3.3 Scelta metodi per i test
Utilizzando questo tool per monitorare l’esecuzione di Adempiere si è riusciti ad elaborare una piccola lista con i metodi che hanno un impatto maggiore sui tempi di esecuzione del programma (Tabella 3.19).
Tabella 3.19 - Elenco metodi più significativi
Package Classe Metodo
org.compiere.model PO load()
org.compiere.model PO saveNew()
org.compiere.model GridTable getField(string) org.compiere.model GridField getColumnName() org.compiere.model GridTab loadField()
org.compiere.grid GridController Init()
org.compiere.util Env getCtx()
org.compiere.util DB prepareStatement(String,String) org.compiere.util Secure decrypt(String)
org.compiere.dbPort Convert_PostgreSQL convertCast(String) org.compiere.dbPort Convert convertStatement()
Dopo aver ottenuto una lista dei metodi più significativi si è passati ad analizzare il codice, in modo da trovare alcuni punti migliorabili.
Ci si è concentrati principalmente solo su alcuni tipi di costrutti e oggetti, come le stringhe e cicli.
Questa analisi manuale ha portato a galla alcuni blocchi di codice che si pensava poco efficienti e che sono stati oggetto di studio per elaborare migliorie energetiche. Il metodo che ha dato particolari spunti è stato il metodo load, metodo che carica i dati presenti in oggetti che rappresentano le colonne di un database. In questo metodo è stato trovato per esempio un blocco di codice costituito da una serie di if concatenati fra loro. La cosa è assolutamente lecita, ma nella fattispecie erano
42
abbastanza numerosi. Si è pensato quindi subito ad un modo per poterlo rendere più efficiente, come per esempio sostituirlo con uno switch.
In altri punti sono stati trovati numerosi cicli for che operano su oggetti particolari. Si è pensato quindi che l’introduzione di un iteratore potesse migliorare le prestazioni. Il metodo Convert ha invece offerto molti spunti per quanto riguarda la manipolazione delle stringhe. Infatti questo metodo effettua delle conversioni di statement in linguaggio SQL, effettuando normali operazioni come creazioni di sottostringhe, comparazioni ecc … Questo tipo di operazioni tipicamente non hanno un grande impatto sui tempi di esecuzione, ma dato che possono essere impiegate molte volte perché di uso comune, anche un piccolo miglioramento potrebbe dar un contributo significativo globalmente.
Verranno successivamente discussi i dettagli dei costrutti in esame e delle possibili migliorie.
3.4 Fase 3: Testing
Per effettuare dei test in maniera precisa e riproducibile si è deciso di seguire questa procedura, ovvero di estrapolare le problematiche riscontrate e creare dei piccoli programmi su cui testarle indipendentemente. In questo modo non è più necessario eseguire l’intero programma Adempiere, ma riprodurre solo le parti interessanti. I test eseguiti possono essere raggruppati in tre categorie:
Test su if concatenati e switch
Test sugli iteratori
Test sulle stringhe
3.4.1 Test su if concatenati e switch
Per eseguire questi test si è creato un piccolo programma che riproducesse una singola funzionalità, focalizzandoci in particolare sul metodo load. Queste sono le classi che compongono il mini programma di test:
43
Classe PO: contiene un oggetto di nome p_info, di tipo POInfo;
Classe POInfo: contiene un array chiamato m_columns, costituito da oggetti di tipi POInfocolumn;
Classe POInfoColumn: contiene le informazioni su una singola colonna della tabella. Vengono indicati l’identificativo della tabella, il nome, le chiavi e alcune informazioni relative alla crittazione e sul tipo di dati contenuti. Presenta un costruttore che riceve tutti questi parametri e li salva in variabili locali. In particolare è presente la variabile
ColumnClass, definita come oggetto generico Class<?>. La sua tipologia
viene scelta in base al valore della stringa columnName e può assumere valori come String, Boolean, Integer, BigDecimal, Timestamp e altri. Esempio codice:
if (columnName.equals(“AD_Language”) ||
columnName.equals(“EntityType”)) {ColumnClass = String.class;}
Nella classe PO viene riportato il metodo load originale, cioè quello presente in Adempiere, il quale presenta un ciclo for sugli oggetti presenti nell’array m_columns presente nell’oggetto p_info. All’interno del ciclo si ottengono i valori di
ColumnName e ColumnClass. Quest’ultimo viene utilizzato come fattore
discriminante nella serie di if concatenati successivi.
for (index = 0; index < size; index++) {
String columnName = p_info.getColumnName(index); Class<?> clazz = p_info.getColumnClass(index); int dt = p_info.getColumnDisplayType(index);
if (clazz == Integer.class)
44
else if (clazz == BigDecimal.class)
{…};
else if (clazz == Boolean.class)
{…};
else if (clazz == Timestamp.class)
{…}; {…} }
Figura 3.6 - Class Diagram del programma usato per il test su if concatenati
Una possibile alternativa al codice sopra riportato è quella di sostituire gli if con uno switch. Sorge però un problema: questo costrutto è in grado di lavorare esclusivamente con oggetti di tipo intero o enumerativi.
45
Per non modificare anche le altre classi si è pensato ad una soluzione alternativa, ovvero fare in modo di mappare gli oggetti di tipo class in enumerativi.
Per prima cosa è necessario creare un tipo enum con i valori che può assumere la variabile ColumnClass.
public enum TipoClasse {
String, Integer, BigDecimal, Boolean, altro; }
Bisogna ora ottenere questi valori, estrapolandoli dall’oggetto clazz. Per prima cosa è necessario ottenere una stringa con il nome completo del tipo classe mediante un semplice metodo toString() applicato all’oggetto clazz. I risultati saranno del tipo class java.lang.String, oppure java.math.Integer ecc … Successivamente si deve ottenere la sottostringa eliminando la prima parte non interessante e lasciando solo il tipo di classe presente nell’enum, come String o Integer.
Utilizzando Java 7 è possibile utilizzare direttamente le stringhe nella valutazione dello switch. Non è stato però utilizzato in quanto si è preferito un metodo standard e retro compatibile.
A questo punto si è potuto applicare lo switch utilizzando il metodo valueOf, il quale associa il valore del parametro passato ad un oggetto del tipo enum definito precedentemente.
Class<?> clazz = p_info.getColumnClass(index); String clazz2 = clazz.toString().substring(16);
switch (TipoClasse.valueOf(clazz2)) {
case altro:
{…};
case String:
46 break; case Integer: {…}; break; case BigDecimal: {…}; break; case Boolean: {…}; break; }
All’interno dei case sono state sostituite tutte le istruzione con delle semplici stampe a video, in modo da evidenziare i tempi di esecuzione dei costrutti esaminati rispetto ai metodi chiamati all’interno.
L’array m_columns contenente oggetti di tipo POInfoColumn è stato popolato artificialmente con 10 oggetti e si è fatto in modo che in entrambi i casi il numero di if o di case esaminati fosse lo stesso.
Sono stati sempre eseguiti almeno 5 test per poi fare una media dei risultati ottenuti. Si è sempre controllato che i dati fossero coerenti tra loro facendo in modo che il valore della confidenza sul valore medio fosse al di sotto del 5%. Ecco in dettaglio un esempio (Tabella 3.20).
Tabella 3.20 - Dati di esempio per il calcolo della confidenza
Dato 1 Dato 2 Dato 3 Dato 4 Dato 5 Valore 0,146766 0,143082 0,146158 0,143957 0,144131
47 Numero valori: 5
Media: 0.144819
Deviazione standard = 0.0016 Alfa (sempre costante) = 0.05 Confidenza = 0.0014
Confidenza / Media = 0.9%
Nel caso in cui questo valore superasse la soglia del 5% verrebbero ripetuti i test e ottenuti nuovi dati. Questa procedura è necessaria per evitare che certi valori fuori dalla norma o errori occasionali influiscano sui valori medi.
Oltre a questo test ne sono stati eseguiti altri per monitorare il comportamento del programma alla modifica di alcuni parametri, come il numero di if concatenati o case presenti e il numero di oggetti presenti nell’array su cui fare la valutazione.
Si è inoltre considerata l’ipotesi di sostituire il ciclo for con un equivalente ciclo while, in modo da valutare quale dei due fosse il più efficiente.
3.4.2 Test sugli iteratori
La seconda problematica su cui si è lavorato riguarda i cicli for, in cui potrebbe essere conveniente utilizzare degli iteratori.
Gli iteratori permettono di valutare gli elementi presenti in un contenitore, come un vettore o una lista, indipendentemente dal tipo di oggetto presente. Il meccanismo di iterazione si preoccupa di ricordare quali elementi sono già stati esaminati e quale il prossimo.
Per poter utilizzare un iteratore sono necessari questi passi:
Implementare l’interfaccia Iterator, che comprende la definizione di alcuni metodi (di solito l’implementazione avviene utilizzando le inner classes, ovvero viene definita all’interno della classe del contenitore):
48
boolean hasnext(), che ritorna true se esistono ancora elementi da visitare;
Object next(), che ritorna l’elemento successivo;
void remove(), che rimuove l’ultimo elemento ritornato dall’iteratore.
Definire e implementare nel tipo contenitore un metodo che restituisce un iteratore.
Per effettuare i test si è utilizzato lo stesso programma implementato per il test sullo switch, ma chiaramente sostituendo il ciclo for con un iteratore.
Per maggiore chiarezza verranno riportati i pezzi di codice che riguardano l’implementazione dell’iteratore.
Classe POInfo:
public class POInfo {
Vector<POInfoColumn> v = new Vector<POInfoColumn>();
/**
* Costruttore Classe POInfo */
public POInfo () {
for (int i = 0; i < 10; i++) {…}
} /**
* Implementazione dell’interfaccia Iterator */
class VIterator implements Iterator<Object> {
private int i;
VIterator() {
i = 0;
}
public boolean hasNext() {
return i < v.size(); }
49
public Object next() {
if (i < v.size()) {
i++;
return v.get(i - 1);
} else
throw new NoSuchElementException(""); }
public void remove() { }
} /**
* Metodo che restituisce un nuovo iteratore */
public Iterator<?> iterator() {
return new VIterator(); }
}
Metodo load della classe PO:
public void load() {
Iterator<?> it = p_info.v.iterator();
while (it.hasNext()) {…} }
I test si sono svolti su quattro versioni del programma utilizzato per lo switch, provando tutte le combinazioni possibili, ovvero:
Metodo load con ciclo for e all’interno una serie di if concatenati.
Metodo load con ciclo for e all’interno uno switch.
Metodo load con iteratore e all’interno una serie di if concatenati.
