di classi:
∗ Model, che estendono la classe base CI_Model, i quali sono la chiave di accesso ai dati dell’applicazione. Si è deciso di realizzare un model per ogni tabella presente nel database;
∗ View, che generano il codice HTML di ogni pagina (o porzione di essa). Alle view è possibile passare delle variabili in modo da rendere dinamico il loro contenuto.
∗ Controller, che estendono la classe base CI_Controller e istanziano le view popolandole con i dati provenienti dai model. La particolarità di queste classi è che i loro metodi pubblici si possono chiamare direttamente tramite URL. Codeigniter, infatti, implementa un meccanismo (grazie al magic method __call ) per il quale è possibile chiamare un metodo pubblico a di una classe controller C semplicemente recandosi all’url nomedelsito.dominio/C/a (ad esempio crociereregalo.it/C/a).
Tale meccanismo risulta molto utile nella realizzazione diAPIe nella creazione di URL user-friendly (quindi più leggibili)
Codeigniter, inoltre, presenta un modulo personalizzato per interagire con il database, che supporta funzionalità come il log delle query (in pratica è possibile sapere l’ultima query eseguita, molto utile in caso di debug ), meccanismi di query building (creazione assitita di query), query parametrizzate, gestione delle transazioni ecc.
3.3 Ottimizzazione delle performance del database
3.3.1 Il problema
Il sito CrociereRegalo soffriva di un grande problema: la lentezza di caricamento delle pagine. Tale lentezza era dovuta principalmente all’elevato numero di query complesse presenti in ogni pagina, ciascuna delle quali aveva dei tempi di esecuzione nell’ordine dei secondi che, complessivamente, facevano sì che il tempo di caricamento di alcune pagine (in primis quella di visualizzazione dei risultati di una ricerca) lambisse pericolosamente
il minuto.
3.3.2 La soluzione trovata
Dopo un’attenta analisi del database, è emerso che molte tabelle non avevano una corretta struttura. In particolare, su alcune non vi era definita alcuna chiave primaria, mentre in generale non erano presenti chiavi esterne ed indici. Sono quindi state definite chiavi esterne e primarie per tutte le tabelle, mentre per la creazione di indici ci si è affidati all’analisi delle principali query grazie allo strumento Database Tuning Engine Advisor integrato nella suite di SQL Server. Vengono ora riportati due esempi di analisi svolta e di risultati ottenuti.
Query di ricerca
22 CAPITOLO 3. RESOCONTO DELLO STAGE
F R O M C r u i s e s _ I t i n e r a r y L i s t il i n n e r j o i n C r u i s e s _ L i n e s l on il . S u p p l i e r = l . S u p p l i e r i n n e r j o i n C r u i s e s _ P o r t s po 1 on ( po 1. C o d e
= il . D e p a r t i n g P o r t and po 1. S u p p l i e r = il . S u p p l i e r ) i n n e r j o i n C r u i s e s _ P o r t s po 2 on ( po 2. C o d e = il . E n d P o r t and po 2.
S u p p l i e r = il . S u p p l i e r ) i n n e r j o i n C r u i s e s _ S h i p sp on ( sp . S u p p l i e r = il . S u p p l i e r and sp . C o d e = il . S h i p C o d e ) i n n e r j o i n C r u i s e s _ P r i c e s p on ( p . S u p p l i e r = il . S u p p l i e r and p . C r u i s e I d = il . C r u i s e I D and p . C r u i s e C a t e g o r y A v a i l a b l e =1) i n n e r j o i n C r u i s e s _ I t i n e r a r y it on ( it . S u p p l i e r = il . S u p p l i e r and il . I t i n e r a r y C o d e = it . C o d e )
W H E R E il . S u p p l i e r =1 AND il . A v a i l a b i l i t y S t a t u s C o d e = ’ AV ’ AND B e s t P r i c e > 0
G R O U P By l . S u p p l i e r , l . NameIT , l . D e s c r i p t i o n , l . Logo , il . S h i p C o d e , il . S a i l i n g L e n g t h D a y s , il . I t i n e r a r y C o d e , po 1. Code , po 2. Code , po 1. Name , po 2. N a m e , sp . ImgUrl , it . G r a p h i c s U r l , sp . N a m e o r d e r by
M i n S a i l i n g D a t e , P o r t o A r r i v o , I t i n e r a r y C o d e
Questa è una delle query (la più esterna) che viene usata nel caso di ricerca di un itinerario filtrandolo per fornitore (in questo caso MSC Crociere) i cui esiti vengono utilizzati per creare la schermata presente in Figura 3.4. Il problema di questa interrogazione, oltre alla lunghezza, è l’elevato numero di JOIN tra tabelle aventi un ingente quantitativo di dati, nello specifico:
∗ Cruises_Prices: 424 780 righe
∗ Cruises_ItineraryList: 8 092 righe
∗ Cruises_Ports: 4 187 righe
∗ Cruises_Itinerary: 2 985 righe
Figura 3.4: Esempio di utilizzo del risultato della query della ricerca.
3.3. OTTIMIZZAZIONE DELLE PERFORMANCE DEL DATABASE 23 Tali tabelle erano per lo più sprovviste di indici, pertanto le operazioni di JOIN risul-tavano molto costose. Come risultato si otteneva un tempo di esecuzione, nel server di produzione in assenza di sovraccarichi, variabile tra 23 e 25 secondi. Grazie al tool Database Tuning Engine Advisor sono stati creati dei nuovi indici, precisamente su tutte le colonne coinvolte nelle clausole di JOIN. Questo ha portato un ingente riduzione nei tempi di esecuzione della query, che sono arrivati a sfiorare i 2 secondi. Vi è stato, quindi, un miglioramento di ben 21 secondi (circa il 91%) nel tempo di esecuzione della query e di conseguenza neltempo di rispostadella pagina web incaricata di elaborare e visualizzare i risultati della ricerca.
Query dei last minute
In homepage vi è una sezione che visualizza tutte le offerte last minute (ovvero crociere prossime alla partenza aventi ancora posti disponibili a prezzo scontato) presenti nel database, come mostrato in Figura 3.5. Queste ultime vengono inserite a mano dai dipendenti di Primarete, ma sono collegate a crociere effettivamente presenti. La query sottostante restituisce tali offerte.
Figura 3.5: Esempio di utilizzo del risultato della query dei last minute.
S E L E C T d i s t i n c t top 4 l . Logo , l . N a m e I T as S u p p l i e r N a m e , il . S u p pl i e r , il . C r u i s e I D , il . S h i p C od e , il . I t i n e r a r y C o d e , il . D e p a r t i n g P o r t , il . EndPort , il . S a i l i n g D a t e , il . R e t u r n D a t e , il . S a i l i n g L e n g t h D a y s as N i g h t N u m b e r , po . N a m e as P a r t e n z a , po 2. N a m e as Arrivo , s . foto , sp . ImgUrl , min ( p . B e s t P r i c e ) as B e s t P r i c e F R O M C r u i s e s _
I t i n e r a r y L i s t il j o i n C r u i s e s _ P r i c e s p on il . C r u i s e I D = p . C r u i s e I d j o i n C r u i s e s _ P o r t s po on ( il . D e p a r t i n g P o r t = po . C o d e and po . S u p p l i e r = il . s u p p l i e r ) j o in C r u i s e s _ P o r t s po 2 on ( il . E n d P o r t = po 2. C o d e and po 2. S u p p l i e r = il . s u p p l i e r ) j o i n C r u i s e s _ S h i p sp on ( sp . C o d e = il . S h i p C o d e and sp . S u p p l i e r = il . S u p p l i e r ) j o i n C r u i s e s _ L i n e s l on ( l . S u p p l i e r = il . S u p p l i e r ) l e f t j o i n C r u i s e s _ B a n n e r AS b ON b . t ip o = ’ nave ’ AND b . r i f e r i m e n t o = C O N C A T ( il . S up p l i e r , ’ - ’ , il . S h i p C o d e ) I N N E R J O I N C r u i s e s _ B a n n e r _ S l i d e AS s ON b . id = s . b a n n e r AND s . n o m e = ’ nave ’
W H E R E S a i l i n g D a t e B E T W E E N ’2018 -09 -09 ’ and ’2018 -10 -09 ’ and A v a i l a b i l i t y S t a t u s C o d e = ’ AV ’ and il . s u p p l i e r = 2 and po . S u p p l i e r = 2 and po 2. S u p p l i e r =2 and p . B e s t P r i c e >0 g r o u p by l . Logo , l . NameIT , il . S u p p l i e r , il . C ru i s e I D , il . S h i p C o d e , il .
24 CAPITOLO 3. RESOCONTO DELLO STAGE
I t i n e r a r y C o d e , il . D e p a r t i n g P o r t , il . EndPort , il . S a i l i n g D a t e , il . R e t u r n D a t e , il . S a i l i n g L e n g t h D a y s , po . N a m e , po 2. N a m e , s . foto , sp . I m g U r l
Anche qua, il numero di JOIN su tabelle aventi ingenti quantità di dati rende il tempo di esecuzione della query molto elevato in caso il database non sia sufficientemente ottimizzato. Grazie alle ottimizzazioni suggerite dal tool Database Tuning Engine Advisor, si è avuto un miglioramento del tempo di esecuzione indicativamente dell’83%, che è passato da 3 secondi a 0.5. Tale miglioramento si è riflettuto anche nelle performance della homepage, che ha visto una netta diminuzione del tempo medio di risposta.
3.3.3 Risultati delle ottimizzazioni
Al termine delle ottimizzazioni, sono stati ottenuti buoni risultati (iltempo di risposta del sito è diminuito di almeno il 50%), ma non abbastanza per rendere il sito reattivo ed equiparabile in termini di velocità ai competitor. Si è deciso quindi di esplorare nuove soluzioni.