 Allora, sono le 14 e 30, Track 2 World Camp Torino 2013. Grazie di essere qui. Abbiamo, appunto, iniziamo con il talk di Fabrizio, Fabrizio Leo. Chi è Fabrizio Leo? Fabrizio Leo è una persona che usa WordPress da una vita. Adia a vista di tutti i colori, a vista di versioni di WordPress, ferma la release 4.5, usa appunto WordPress come se fosse un amico di infanzi. È cresciuto insieme a WordPress, quindi il talk di oggi sarà molto interessante, soprattutto perché tratta un mito di WordPress che è quello che WordPress non scala, che questo non ci è messo e che non scala. Ne siamo veramente sicuri? Vediamo, adesso aspettiamo cosa si dice. Fabrizio Leo, grazie. Grazie a te. Buon pomeriggio e lo so che dura cominciare dopo la passo a pranzo, quindi, prego, ok, ci siamo, ok. Allora, diamo di sfegliare un po', diciamo, di sfatere un po' questo falso mito, questa leggenda, WordPress non scala, capiamo, però una domanda, ce l'ho io per voi, insomma, una domanda antiabbiocco, diciamo. Vi siete mai chiesti come fanno diversi siti che gestiscono milioni di utenti realizzati su WordPress? Come fanno a reggere tutto quel traffico? Quindi cerchiamo di capire più o meno, secondo quella che è la mia visione, come fanno. Come già vi è stato anticipato, sono Fabrizio Leo, sono il CEO e il founder di Flame Networks. Oggi, va avanti, sì, ok, perfetto. Un po' di contesto. Abbiamo il blog dei misiocomeri che sta diventando virale. Infatti, chi è tra di voi che non è curioso di sapere qual è la storia di questi misiocomeri, è vero? Il blogger che ha creato questo sito realizzato con WordPress però iniziò ad essere un po' preoccupato, perché in effetti, poiché questo blog sta diventando virale, lui teme che il sito possa non reggere tutti questi utenti. E quindi si chiede come faccio a tenere in piedi il mio sito su WordPress perché non voglio cambiare piattaforma, so usare WordPress, lo padronegio, non voglio passare a una soluzione custom. Quindi, come faccio se non posso scadrare le risorse? Come facciamo ad aiutarlo? Quindi, in suo soccorso, il misiocomero ha trovato chi può dare una risposta a questo suo dubbio miaoletico. Vediamo come. Partiamo da quelli che sono i problemi più comuni che abbiamo poi riscontrato nel corso di tutti questi anni su WordPress. Il peso. Cioè, questo gattone la dice un po' tutta, quindi peso. Temi. PageBuilder, i nostri amati PageBuilder che per quanto possano in qualche modo agevolare la gestione dei contenuti, in realtà poi magari introducono un livello di complessità tale che poi vada a pesantire poi tutta la struttura e anche le immagini hanno, se può rimanere a minore, un impatto. Ora, sui plugin Procedelizia. Che cosa abbiamo trovato? Abbiamo trovato, mediamente, istanze WordPress con un numero di plugin molto, molto imponente, ma plugin non utilizzati. Io vi do, adesso, vi spoilerò una cosa. Se i plugin non utilizzati, se non riutilizzate, toglieteli, non li disattivate. Ok? Se non li usate, cancellateli. Perché questo? Perché in realtà un plugin disattivato è comunque un qualcosa che esiste, se pure in maniera silente, sulla struttura del nostro sito web che, di conseguenza, comunque lo ha pesantice. Io lo so che vi affezionate ai plugin. Lo so. Dite, vabbè lo installo, poi vabbè non mi serve, se magari poi mi servirà tra tot mesi, vabbè non lo tolgo, che peccato, me lo tengo lì, poi un domani lo riaccendo, no. Se non vi serve più, toglietelo, eliminatelo. Abbiamo visto tante istanze WordPress con decine di plugin non usati, disattivati, che ha un alcun senso. Anche perché si possono tranquillmente salvare e esportare le configurazioni un domani doveste averne bisogno di nuovo. È molto semplice reinstallare l'ex novo ed importare la configurazione che poi è stata precedentemente salvata. Che cosa abbiamo trovato? Abbiamo trovato tutta una serie di mancanze di ottimizzazione sulla parte JavaScript, assenza di cache e sulla parte di infrastruttura. Che cosa vuol dire? Volevo dire che infrastruttura magari non adeguatamente dimensionata o non adeguatamente ottimizzata, l'assenza di diversi strati di cache e l'assenza di ottimizzazioni dei JS. Quindi no lazy load, no object caching, no load balancing, come diceva una vecchia pubblicità possono essere dolori. E in effetti, quando parliamo di minificazione e compressione dei fogli di stile, quindi c'è sss JavaScript, che cos'è? Minifiché? Che cos'è la minificazione? La minificazione è una tecnica che consente di comprimere quelle che sono le nostre risorse statiche. Un sito WordPress è composto da diverse risorse statiche, ovvero fogli di stile, JavaScript font, immagini. Quindi quando io vado a minificare cioè a compattare JavaScript e CSS, sto riducendo in termini volumetrici, in termini di volume di dati che poi il browser va scaricare, sto riducendo questi dati. Quindi il client, l'ultente che va a consultare le pagine web deve scaricare meno informazioni. In ultimo non per importanza tutta la parte database, ovvero sappiamo che WordPress è un CMS sviluppato in PHP che utilizza come suo back-end un database relazionale. Quindi all'interno di questo database che, pardon, è composto da tabelle, all'interno di queste tabelle ci sono tutta una serie di informazioni che vengono recuperate on the fly dal nostro CMS, quindi post, pagine, tutto quello che serve, viene reperito dalla base dati. Ok? Quando però ci troviamo in situazioni di un overuse database, c'è qualcosa che probabilmente non quadra. Quindi, nei momenti in cui io devo aspettare un tot di tempo affinché il DB mi restituisca le informazioni, è tutto tempo che l'ultente sta aspettando per ricevere poi le pagine che ha richiesto e questo chiaramente non va bene. E quindi, ora che abbiamo visto quelle che sono le problematiche di criticità più diffuse, come facciamo ad ottimizzarle? Occorre un'analisi preliminare. Quindi prima di compiere qualsiasi ottimizzazione dobbiamo sapere cosa ottimizzare. Geniale, eh? Bene. Può essere una parte noiosa questa, una parte complessa che richiede delle competenze, ma credetemi, è tutto lavoro ben speso. Quindi, per sapere cosa ottimizzario devo fare un'analisi. Bene, che cosa vado ad analizzare? Fortunatamente ho tutta una serie di strumenti che mi possono dare una mano, cioè monitorare l'utilizzo di risorse di sistema. Io voglio sapere costantemente e magari anche con una storicità l'andamento di l'utilizzo di risorse di sistema, lo stato di salute del sistema che ospita la mia instanza a WordPress. Ci sono diversi sistemi e tecnologie che ci aiutano. Ad esempio, prodotto molto interessante open source è Zabix. È uno strumento potentissimo che è sostanzialmente un agent che si installa all'interno del server, che poi invia tutta una serie di informazioni a un cervellone, diciamo a un server Zabix, che colleziona questi dati. Cosa importante, oltre a collezionare queste informazioni, crea di grafici e l'historicizza. Quindi, io posso avere nel tempo, con tezza dell'andamento dell'utilizzo di risorse. E capire magari perché il mio sito in un determinato momento era allentato, vado a vedere il riscontro poi sul sistema di monitoraggio che magari con Zabix il grafico del processore mi dava uno spike al 100%. Poi vado a fare l'analisi, ancora più di dettaglio. Cosa vado a controllare? Vado a fare un'analisi sui log. Log è un registro e un file che contiene tutta una serie di informazioni utili per analisi e troubleshooting. All'interno di questo registro io posso andare a riscontrare tutti quelli che sono gli accessi al mio sito WordPress. Perché poi, a che cosa serve fare questa analisi su log? In una condizione di operatività normale, io avrò sempre gli accessi tracciati tra le varie informazioni, perché un log viene scritta una riga che ha tutta una serie di informazioni. In questa riga c'è il response code del web server, che normalmente, in caso di operatività normale, il server web risponde un numerico che è 200, cioè ok. Vuol dire che il web server ha risposto il contenuto che ha fornito il contenuto che è stato richiesto dall'utente. L'analisi sui log del server web mi serve per capire se ci sono degli errori 500, la classe degli errori 500 è miscidiale, perché sono errori che poi hanno come diretta conseguenza l'impossibilità per l'utente di visualizzare con la pagina web. Vi fa musero di 500, le pagine bianche, white screen of death, 500, 502, 504, sono dei time out, l'auto server, che possono essere un sintomo di un problema ben più grave, magari satturazione di risorse e quindi ritorno al monitoraggio del sistema. Oppure può essere, magari, un problema su PHP, su la catena laborativa, quindi il web server in realtà ha risposto 502 o 504 perché il PHP ci ha messo troppo tempo a rispondere. E poi in ultimo c'è tutto il profiling sull'applicazione, cioè così come io posso fare sul sistema il monitoraggio è capire come sta andando, io posso fare la stessa cosa sull'applicazione con degli strumenti di profiling, cioè scopercio il vaso di Pandora, ok, ci vado a vedere dentro che cosa sta succedendo sulla mia istanza WordPress. Ci sono degli strumenti nativi, ci sono tutta una serie di plug-in WordPress che mi aiutano a fare un'analisi di merito per capire poi il livello di ottimizzazione della mia istanza WordPress o degli strumenti esterni come ad esempio New Relic, è uno strumento potentissimo che ci dà tantissime informazioni sullo stato di ottimizzazione di salute della mia istanza WordPress. Quindi in base ai risultati che ho raccolto posso poi decidere dove andare ad ottimizzare. Qui si apre tutto un mondo di ottimizzazioni lato infrastruttura barra server, quindi diciamo sono attività che non competono tanto al devello per ma all'amministratore di sistema, quindi il vostro hosting provider diciamo ha la competenza, dovrebbe avere la competenza e la responsabilità di tutta questa roba qui, ovvero ottimizzare la parte web server, quindi vedere se nginx o apaci sono ben ottimizzati, sono configurati bene. La compressione e il caching delle risorse statiche, questa è una parte che in realtà è trasversale perché la compressione delle risorse statiche è un qualcosa che viene effettuata a livello applicazione, quindi su WordPress. Il caching delle risorse statiche è un qualcosa che può essere fatto sia su WordPress ma anche a livello web server. PHP, quello è uno dei principali problemi, lì si possono creare tanti colli di bottiglia che rallentano poi il corretto flusso all'interno di un'elaborazione canonica per fornire le pagine ai nostri utenti. Io lo so che usate ancora PHP 7, lo so. O5 6, io non vi faccio niente, ok? Io non vi faccio niente, però diciamo ce l'ho insomma. PHP 7, end of life, end of support, end of tutto, ok? Unica cosa certe che è bucabile, quindi attenzione alla sicurezza, ok? Quindi il mio consiglio è cambiare, switchare compatibilmente con la nostra istanza WordPress a PHP 8 che è un progetto vivo, vegeto, supportato, che è migliore di PHP 7, si nota subito una differenza dal punto di vista prestazionale perché è cambiata livello d'architetturale, tante, sono cambiate tante cose e soprattutto perché un progetto vivo vengono rilasciate le migliorie e vengono rilasciate le pecce di sicurezza. E poi per quanto riguarda sempre la parte front end, c'è tutta la questione relativa alla parte di accelerazione HTTP, avete mai sentito parlare di varnish cache, sapete più o meno che cos'è? Qualcuno che mi alza la mano e mi sa dire che cos'è? Ok, diciamo che in generale possiamo definire un reverse proxy che funge da botole di caching, giusto? Perfetto. Varnish cache è una tecnologia fortunatela in open source, potentissima. Maggiate che con varnish cache ci girano tanti servizi streaming a pagamento, ok? Quindi l'installazione e fine tuning di varnish cache è strategica e fondamentale per l'ottimizzazione di tutta quella che è la parte del front end per creare un cuscinetto che aiuta il sistema a non soffrire di quelle che sono i famosi spike di utilizzo di risorse, di processore di memoria. Quindi varnish cache prende la nostra pagina, è un sistema che scrive nella memoria del sistema, il cui accesso poi è molto più veloce rispetto all'accesso sul disco. Quindi però non prende la pagina e la butta su file system, no. Crea un'indice ed è a chiavi varnish. Quindi il sistema di caching non va a prendersi la pagina, va a prendersi la referenza che poi punta alla pagina che il utente ha chiesto, senza passare dalle elaborazioni canoniche, quindi web server, PHP interrelazione alla database e tutto poi il flusso in uscita. Poi c'è tutta la parte di ottimizzazione del back end. Quindi fine tuning della parte database come vi dicevo prima, WordPress usa PHP e usa un database relazionale. Capire l'installio di salute del mio database server. L'analisi delle slow queries che altrettanto fondamentale, chi è? Chi sa che cosa sono le slow queries? Nessuno? Ok, cosa sono? Ok, allora così come per il web server, così come per il web server esiste un registro, un file di log, anche su database server è possibile abilitare il log delle slow queries. È un file che viene scritto e che contiene esattamente le interrogazioni alla base dati della nostra estanza WordPress che impiega più di un totto di tempo per essere seguita. Quindi immaginate che se ho anche una sola query su database che impiega 5 secondi, vuoi dire che io utente sto aspettando almeno 5 secondi affinché la pagina web vi venga restituita e poi utilizzare anche un sistema come elastic search o apaci-solder. E se poi dopo tutto questo tenepenti? No, ovviamente scherzo. E se poi non basta? Allora vuol dire che dobbiamo scalare. Quindi ritorniamo al discorso WordPress non scalano ma come un casino? No, capiamo. Sono due tipi di scalabilità. Verticale e orizzontale. Scalabilità verticale vuol dire che aggiungo risorse al mio server ed è abbastanza semplice. Scalabilità orizzontale invece vado a ripartire il workload, quindi il carico della mia applicazione su più sistemi che lavorano in simultanea. E quindi ritorniamo alla fase di monitoraggio. Che cosa succede alla fine dell'analisi che abbiamo fatto? Dobbiamo incrementare il numero dei frontend. Il web server non è uno solo ma n, ne sono n. Anche l'assista cosa vale anche sulla parte database. Quindi non è un solo server database ma sono n server database. E questo è una rappresentazione di quello che può essere la parte web e come scalare, come distribuire il workload su più sistemi. C'è un bilanciatore davanti pubblico esposto su internet che può essere banalmente un Linux. Dietro ci sono in questo caso quattro web server. Possono essere 10, 20. Il bilanciatore fa da passacarte, smista le varie chiamate ai web server in maniera omogenea anche per quanto riguarda l'approccio su database server. Ci troviamo dinanzi a i vari web server che leggono su le repliche MySQL e scrivono sul master. Quindi io posso andare a ripartire le interrogazioni se è una lettura o se è una scrittura, come con hyperdb. Questa è una cosa che io posso fare a livello applicativo. Quindi capite che quindi spero di aver vittato diciamo qualche spunto di riflessione su come effettivamente può scalare WordPress. Noi ricordiamoci sempre che WordPress è una applicazione che è PHP Base, che ha bisogno di un database relazionale. Di tutta questa roba qui. WordPress non sa niente. Completamente agnostico ed è trasparente per l'applicazione. Siamo noi, come amministratore di sistema, dobbiamo essere in grado di implementare un'architettura di questo tipo. Quindi la domanda che vi ho fatto all'inizio. Come fanno testate giornalistiche importanti ma anche siti web importanti che gestiscono migliaia di accessi simultanei. E ma sono realizzati con WordPress. Eh ma WordPress non scala. Ma in realtà non è vero. Non è assolutamente vera questa cosa. Stalabilità di chi padronei gesti sistemi implementa l'architettura di questo tipo affinché per WordPress è come se stesse su un server con un solo web server e un singolo database server. Per il resto è tutto trasparente. Quindi chi pensava che WordPress non scalasse probabilmente inizia a ricredersi. Io ho terminato e vi ringrazio per l'attenzione. Grazie. Il talk è stato interessantissimo. Abbiamo un po' di spazio per le domande quindi visto che il talk inter- vai. Solo ovviamente un istante ed è solo un complimento per l'interessante talk. E volevo aggiungere anche una piccola cosa. Ho visto varie realtà che magari anche molto grosse e purtroppo non scelgono WordPress proprio per questo motivo. Perché tanti credono che WordPress sia solo per il bloggerilino. Cos'è? No, è solo un complimento per l'interessante talk. Grazie. Un punto di partenza interessante per anche un punto di attenzione. Grazie, grazie Matteo. Chi vuole fare la domanda? Se vuole possiamo anche dagli una mascherina. Quindi è così anche più tranquillo con il microfono. Se volete sono qua a disposizione. Altre eventuali domande. Sul piec. Sì. Ecco. Ovviamente tutto questo non è incompatibile anzi avrebbe solo da ricavarne se in in Bando passa mi il termine con un sistema CDN. No. No. No. Ho menzionato nel mio speech CDN. Appunto era quello che mi incuriosiva. No. Allora, eh, la cidna cdn può aiutare, ok, ma non aiuta nel ripartire il carico. Se io ho un'istanza WordPress che deve gestire dieci mila autenti simultanei, non mi serve la cdn. A me serve un bilanciatore con un'architettura distribuita, ok, perché io devo poter far fronte a quella mole di traffico. Se io poi con la cdn ho spostato i contenuti statici. CSS, JavaScript, imagini font perché di questo stiamo parlando. Ho spostato un pezzettino della mia applicazione altrove che marrei ho distribuito su n nodi, ok? Perfetto. Ma elaborazione php, la interrogazione al database. Comunque in ogni caso vanno fatte, ok? E quindi se io ho dieci mila autenti che devo servire non posso pensare di farlo con una cdn, almeno che non rendo il sito statico. E li non stiamo parlando di altro, vero? Stiamo parlando di HTML, ok? E li non c'è bisogno di mettere in piedi tutta quella architettura distribuita. Qui stiamo parlando di implementare un sistema che possa scalare facilmente orizzontalmente affronte di un maggior traffico e soprattutto che garantisca all'utente una performance ottimale. Stiamo parlando di pochi mili secondi di tempo di risposta, un ttfb massimo di 40-50 mili secondi, ok? E non è un qualcosa che si ottiene con una cdn. Cioè se hai una esigenza di traffico di quel tipo non è pensabile, non è quello l'approccio. L'approccio è distribuire il carico su più sistemi perché la scalabilità verticale ha un limite. Dopodiché devi ragionare ripartendo il carico in maniera appunto orizzontale. Poi per inciso varnish cache può essere utilizzato anche come sistema di cdn. Però non è questo diciamo il suo ambito di applicazione di cui stiamo parlando adesso. Perfetto, altre domande? Tutto chiaro. Io ne avrei una, posso? Ma certo. Come si può far a convincere le persone appunto? Quella parte dell'upgrade del PHP e della consapevolezza dell'importanza quindi dell'infrastruttura che ci sta dietro a Wordpress è una consapevolezza appunto forse poco presente. Come si può fare per comunicare al meglio con i clienti, con il produttore? Ok, allora se stiamo parlando di utilizzare software aggiornato, quindi entriamo nell'ambito diciamo della sicurezza, io ti posso rispondere in due modi. La risposta che mi sento di darti soft è fare prevenzione. Quindi anche come ci dicevamo prima, non aspetto i ladri e poi metto la porta blindata. Ok, quindi prevenire. Quindi vuol dire avere un po' di sensibilità in più rispetto a quelle che sono le tematiche della sicurezza. Noi stiamo parlando di software che è sostanzialmente open source e non ha risorse inestimabile. Ok, e fortunatamente lo è. Quindi non c'è il concetto di security through obscurity, tu non conosci il codice quindi non lo sai che cosa ci sta dentro e pure escono le problematiche di sicurezza. Qui stiamo parlando di un software aperto che fortunatamente è manutenuto ed è controllato da tante persone e quindi è normale che escono le problematiche di sicurezza. Quindi io dico ci sono tantissime risorse su internet gratuite che pubblicano costantemente gli advisory fanno public disclosure di problemi di sicurezza. Non aspettate che vi buchino il sito per fare l'aggiornamento perché tardi è troppo tardi. Cioè poi può succedere perché magari ci può essere una vulnerabilità sconosciuta uno zero day perché spesso succede che una vulnerabilità prima di farne public disclosure passano mesi quindi nel frattempo ne hanno bucati di siti. Però quando esce la vulnerabilità bisogna darsi una polisi dire entro 24 ore io devo aggiornare punto poi sì hai voglia ad andare dal provider mi hanno bucato il sito le lacrimucce. Il backup è aggiornato ok ma non c'è arrivare in quella condizione ok soprattutto se parliamo di siti importanti su cui si poge il business di aziende se parliamo di commerce peggio ancora quindi attenzione quindi la risposta è utilizzare ma anche la condizia di sistema perché non è solo il PHP è tutto il web server il kernel linux cioè è tutto un insieme però appunto la domanda e nasce proprio fatto che molto i frilensi o molti persone si trovano in difficoltà a spiegare i loro clienti questa necessità quindi a volte il cliente stesso sceglie un piano di hosting base e obsoleto tutto quanto poi le cose vanno male e ce la si prende o col frilensi o con lo sviluppatore quindi c'è una difficoltà probabilmente da parte proprio comunicativa per spiegare queste cose al cliente che magari ha un e commerce di birra non sa niente di warp di engines eccetera e non capisce sembra quasi che gli si fa spendere i soldi in più diciamo tu mi tu mi vuoi va spendere di più però in realtà io ho visto che c'è quel piano da 10 euro e prendo quelle vabbè e sì ok allora bisogna ragionare diciamo su per come dire metafore ok tu paghi avrai boso avremo un'automobile qualcuno avrà un'automobile di proprietà si paga la risposta il re ci auto giusto ma questo non vuol dire che cioè posto che obbligato la per legge ok ma al di là di questo io pago l'erci auto per stare tranquillo che in caso di sinistro c'è l'assicurazione che mi copre quindi avere un sistema aggiornato è qualche modo una garanzia che quanto meno mi mi riduce il rischio di espormia tutta una serie di problematiche di sicurezza quindi è un po questo il ragionamento da fare e diciamo è un cambio di paradigma culturale indubbiamente e io vado avanti se avete domande ti do conferma totalmente cioè noi non faccio pubblicità perché non è carino però mi trovate di là quindi il circa il 30 per cento degli hosting che abbiamo sono in php 5.6 il però questa è una mancanza del fornitore no no e non possiamo intervenire noi cioè noi forniamo tanto l'hosting noi possiamo anche dare comunicazione all'agenzia e l'agenzia che deve cliccare sul pulsantino e portarlo a 8.1 e lì è disponibile però ti sei dato la risposta posso dire i 70% di city non sono ultima release di warpress parlando dei city warpress questo significa tutto no ci sanno che noi abbiamo di fronte bit ninja abbiamo di fronte tutto per tutta la riutenti ma poi passano quando hai un 4.5 come warpress o hai php 5 e 6 beh lì aspetti soltanto che succeda tutto lì true story è indubbiamente cioè io lo vedo tutti i giorni per il lavoro che faccio che vedo tutti i giorni purtroppo ok il punto è se cioè banalmente se il sistema integrator da due badgen si chiamiamola come vogliamo non non rispetta una diciamo determinati requisiti ok secondo me la scelta è molto semplice sì come giustissimo però noi siamo proprio volte spesso in una catena schiacciati oppure diciamo diciamo che se uno è tipo la persona che sa queste cose però si ritrova l'agenzia davanti con il cliente davanti e soprattutto anche per le invece le prestazioni quindi non solo la sicurezza anche le prestazioni è difficilissimo motivare soprattutto in termini di costo perché poi il cliente volte punta spesso senza sapere le conseguenze sia in performance sia in sicurezza alla all'economicità della scelta vero ma vedi in comunicare è più possibile trovare il mondo diciamo che io io da come dire operatore del settore cerco di dichiarare un po di sensibilità su questi argomenti poi ci spendiamo molto su queste cose soprattutto con i nostri partner e con le persone che lavorano con noi poi è chiaro che poi arriviamo a un certo punto che non ha senso questo accannimento terapeutico lasciami dire c'è ognuno poi attefice del proprio destino perdonami non possiamo esatto però uno deve essere professionale al punto da dire guarda se non fai questo puoi andare incontro a tutta una serie di conseguenze fine poi come si dice a napoli attacca il ciuccio dove dice il padrone ok quindi non siamo le mani poi in termini per quando guarda le performance dipende dal progetto perché anche in altri speech che ho portato in giro in passato 500 mili secondi di tempo di attesa di caricamento su un sito e commerce vuol dire il 40% di fatturato in meno più o meno quando tu vedi al merchant e dici tu fatturi 2 milioni all'anno sei riduci di 500 mili secondi puoi fatturare 2 milioni a mezzo 2 milioni e sei questo penso che ti sta a sentire da fare questi discorso grazie grazie Fabrizio grazie a voi grazie a voi