Io cache, tu database

Editor's Notes

1. Sviluppatore PHP dal 2005 Utilizzo prevalentemente Symfony dal 2007 Dedico tempo alla community in vari modi: - faccio parte del consiglio direttivo del grusp che è l'associazione che organizza phpDay/jsDay e supporta altre associazioni a realizzare eventi in tutta Italia - uno dei fondatori del PUG Friuli - symfony: traduzione documentazione / bugs Nel tempo libero mi dedico al running
2. Non avendo già abbastanza impegni ora anche autore PHP Best Practices in anteprima al phpDay Il primo libro italiano di questo genere. Dalla community per la community. Gli autori fanno parte del GrUSP ed i temi trattati sono davvero interessanti. Mio capitolo dedicato al performance profiling delle applicazini PHP
3. Ci ho preso gusto... Da oltre due anni lavoro da casa Ho deciso di raccontare la mia esperienza Sto scrivendo questo libro
4. Punto di partenza: siti o applicazione le cui performance sono sono il massimo. Posso scommettere un caffè che almeno 1-2 persone per ogni fila di sedie si è trovato in una situazione del genere. In situazioni del genere molto spesso il database è il primo elemento verso cui si punta il dito, a volte questo è vero anche se effettivamente lui fa quello che gli si dice di fare... Si può quindi affermare che si utilizza il db in modo illecito, non è lui ad essere cattivo a prescindere ma lo sviluppatore che ha sbagliato qualcosa....
5. Avere un sistema più performant e grazie ad alcuni accorgimenti che permettono di sfruttare meglio le grisorse a disposizione, in particolare la memoria, oltre che utilizzare gli strumenti in modo corretto e non snaturandoli L'obiettivo è quello di integrare lo stack a disposizione senza imporre migrazioni complete PICCOLE MODIFICHE → GRANDI RISULTATI
6. Il caso più tipico è quello di una nuova applicazione in cui... Tutto fatto sfruttando il db tanto il traffico è basso e la mole di dati da gestire è piccola. Ogni operazione che richiede di scrivere/leggere dati viene fatta con il database Numeri piccoli, tutto funziona
7. Succede poi che si ottiene il successo ipotizzato o succede l'inaspettato ed il sito viene sommerso dalle visite che inevitabilmente rendono il servizio inaccessibile. Ciò che funzionava per 1000 utenti non funziona più per 10000...ed inevitabilmente fanno la loro comparsa errori di questo tipo a seconda delle configurazione dello stack... 503 service unavailable 504 gateway timeout
8. Semplificando parecchio il discorso, il collo di bottiglia principale, parlando di limiti fisici, è rappresentato dai tempi di seek dei dischi su cui il db risiede per posizionare la testina sul punto esatto del disco per leggere le informazioni.. Questo problema diventa più marcato man mano che la quantità di dati aumenta e che il caching effettivo diventa impossibile.
9. Ovviamente il primo pensiero è quello di mettere mano al portafoglio per scalare l'architettura verticalmente (male) od orizzontalmente (bene) andando inevitabilmente ad aumentare la complessità del sistema. La figura non tecnica dice “se serve facciamo spendere il cliente”. Migrare completamente verso altri prodotti che reputiamo più performanti.
10. Prima però forse è il caso di provare a sfruttare gli strumenti già a disposizione in modo migliore, puntando sui loro punti di forza e non pesando sui loro punti deboli... Introdurre strumenti a basso impatto per quanto riguarda lo stack Che integrano e non richiedono una migrazione completa di parti dell'applicazione
11. Area ad accesso rapido sia in lettura che scrittura, operazioni eseguite a basso costo. Inoltre è SEMPRE già a disposizione. Ovviamente ha dei limiti, primo fra tutti non è persistente quindi OCCHIO a cosa ci fate lì dentro! Ok però c'è bisogno di qualcosa che ci permetta di utilizzarla facilmente perchè da buoni sviluppatori siamo pigri...
12. Memcached Sistema distribuito di caching in memoria degli oggetti. Key-value store per stringhe e oggetti dalla natura generica utilizzato principalmente per ottimizzare le performance di applicazioni dinamiche alleviando il carico sui database. Redis advanced key-value store. often referred to as a data structure server since keys can contain strings, hashes, lists, sets and sorted sets. Aggiunge la persistenza dei dati. Vediamo dei casi d'uso...
13. Gestione ed erogazione banner. Poche scritture, contenuti cambiano con bassa frequenza . Molte letture perché è necessario far ruotare le creatività e non è possibile mettere in cache. Spostare tutto in memoria. L'anno scorso verso luglio -40M query/giorno con questo scherzetto. Grafico in picchiata della cpu dei db slave...purtroppo non l'ho trovato. MEMCACHED
14. Impression, views, click, sondaggi... Tutti write-intensive task per il db. Il segreto è quello di incrementare il valore di una chiave per un certo periodo per poi fare scritture ad intervalli regolari. VEDERE COMANDI PER SCRITTURA SICURA MEMCACHED / REDIS
15. Caso classico per avere un punto centralizzato in cui verificare se l'utente è online o meno. Il lifetime di una chiave calza a pennello e leggendo dalla memoria non devo fare operazioni dispendiose sul db ad ogni visualizzazione. Posso inoltre rinnovare il lifetime dopo l'esecuzione di particolari azioni che mi assicurano la presenza dell'utente. MEMCACHED
16. Tutti i casi del tipo - ultimi commenti inseriti dagli utenti - ultimi visitatori del tuo profilo - ultimi qualcosa... Non ha senso dover ordinare dati se ci servono semplicemente nell'ordine in cui sono stati inseriti. LISTE: inserisco commenti con LPUSH al momento della loro creazione, posso impostare dimensione massima LTRIM 0 100, leggo dalla lista ed eventualmente fall back sul db se non ci sono abbastanza elementi REDIS
17. Esempio comune difficile da modellare con buone prestazioni su DB non in memoria: prendere un elenco di elementi, ordinarli in base ad un punteggio, aggiornato in real time, con molti aggiornamenti ogni secondo... Pensate ad un gioco online per esempio dove - mostrare la classifica dei primi 100 - mostrare la posizione del singolo utente Queste operazioni sono banali utilizzando gli INSIEMI ORDINATI (SORTED SETS) anche se si ha a che fare con milioni di utenti e milioni di nuovi punteggi ogni minuto. ZADD leaderboard <score> <username> ZREVRANGE leaderboard 0 99 ZRANK leaderboard <username>
18. Potrebbe essere finito il tempo, qui ci sono dei miei biglietti da visita. Prendeteli pure. Mi trovate più tardi all'aperitivo, alla serata social e anche domani sarò disponibile per qualsiasi informazioni. Fermatemi senza problemi che ci facciamo una chiacchierata.
19. Seguitemi su twitter, contattatemi pure per qualsiasi curiosità o informazione...
20. Votate per favore il talk su joind.in, siate critici senza problemi, date suggerimenti e spunti per migliorare, fatelo per tutti i talk che seguite. Aiuta gli speaker a migliorarsi ed aiuta gli organizzatori a migliorare i contenuti della conferenza per le prossime edizioni. GRAZIE!