ciao ragazzi,
ieri ho avuto una presentazione dinanzi ad un senior architect riguardante un progetto che devo iniziare.
quando ho illustrato l'architettura, e siamo arrivati al punto caching. mi e' stato detto che la cache era inutile ed era possibile andare direttamente sul db perche tanto i server erano vicini e il tempo di risposta del db poteva essere 0.3 s, 0.5 sec.
vorrei delle vostre opinioni, io ho gia le mie.
grazie
john79
scusami potresti spiegarmi meglio il tuo punto di vista che sicuramente non capisco.
se i dati cambiassero ogni 10 sec, forse avresti ragione e avrei sicuramente compreso anche il punto di vista del mio collega.
ma se i dati sono statici, o l'80% di questi dati e' statico, saresti sempre convinto a non introdurre nessuna cache?
gio
>si, la cache tipicamente serve per risolvere un problema prestazionale >e finch� non hai un problema prestazionale (e lo puoi scoprire solo in >produzione) non ha molto senso fare lavoro up-front.
non sono d'accordo, preferisco la frase prevenire e' meglio che curare!
>Quindi di solito io penso l'architettura prendendo in considerazione >che ci dovranno essere degli "extensibility point" per poter pluggare >un eventuale motopre di caching ma poi aspetto, in questo modo se >servisse la cache sarebbe totalmente trasparente all'applicazione, come >del resto � giusto che sia.
d'accordo sugli extensibility point, ma con cache gia implementata. In grandi compagnie i database sono gia sovraccarichi, e se si vanno a controllare le query molte delle volte vengono fatte query inutili, questo perche le persone non danno la giusta importanza alla cache. Da notare anche che un uso ottimizzato della cache potrebbe perfino spostare il carico di lavoro da un server ad un altro. ( dal db al cache server) dando cosi respiro ad un db server gia sovraccarico.
da alcune statistiche create con i performance counter che ho tirato fuori durante una giornata di lavoro di un applicativo . sono stati messi circa 300 oggetti in memoria, questi oggetti sono stati letti durante 24 ore , 300.000 volte e sono state generate 10.000 query. questi dati indicano che utilizzando la cache ho preservato il database da 290.000 query inutili. salvando energia(in nike ci tengono, cpu overload, e incrementando le performance) ma queste cose le sanno tutti, non e' una novita. quindi vedendo questi dati, io personalmente , incoraggio sempre ad usare la cache laddove ne esiste la possibilita, ovviamente non ha senso inserire la cache dove i dati vengono refreshati ogni secondo. E anche se i dati venissero refreshati ogni secondo bisognerebbe valutare l'ipotesi di cachare cio non cambia. e querare il db per cio che cambia. faccio un esempio. in nike ce un database enorme per la definizioen di un materiale. in se per se il materiale ha un ciclo di vita che va per anni, significa che una volta creato l'80% dei dati non cambia mai. puo cambiare il prezzo, la disponibilita, ecc, ma non il colore, il nome , la categoria, e' molto raro. sarebbe ideale avere una parte in cache e una query piccola per prendere il prezzo corrente. in questo modo si salva cpu del db, cosa non da poco.
cheers
Ciao john79,
> non sono d'accordo, preferisco la frase prevenire e' meglio che curare!
ti cito un paragone per cercare di farti vedere la cosa (in generale, nello specifico puoi valutare solo tu) da un punto di vista più "distaccato":
Saprai che esistono gomme termiche invernali per le auto, che migliorano moltissimo l'utilizzo con temperature prossime allo zero ed in caso di neve. Sono accessori utilissimi per chi abita in montagna e comunque comodi anche per chi vive fuori città e guida di notte o la mattina presto con la "brinetta".
Domanda: se tu abitassi in un luogo in cui d'inverno la temperatura raramente scende sotto i 5 gradi e nevica in media una volta ogni 10 anni ed il tuo concessionario ti proponesse le gomme termiche invernali argomentando, tutto sommato giustamente, che col clima che c'è adesso non si sa mai che tempo ti troverai, tu le acquisteresti?
Credo che la risposta possa essere: "dipende da quanti soldi ho a disposizione e da quanto prevedo di utilizzarle". Se hai il conto molto ben "coperto" :-) probabilmente 1K li spenderesti senza problemi anche se poi magari non le userai mai, altrimenti forse potresti preferire spendere quei 1000 Euro per un'altro accessorio che utilizzeresti di più (tetto in vetro, boh...).
Poi... non è per forza sbagliato acquistare un'auto "full-optional", ma l'errore involontario potrebbe essere quello di non dare il dovuto peso all'aspetto iniziale costi/benefici.
Quello suggerito da Mauro (rendere implementabile il caching senza ribaltare niente) è IMHO un ottimo piano, che ti permette di risolvere, senza grandi dolori, il problema "nevicata" quando effettivamente arriva la neve. ;-)
Spero che il paragone sia "valido"... :-)
Ciao!
Mario
ricordo che e' solo un discussione su un forum, chiedere e' lecito rispondere e' cortesia e visto il prolungarsi della discussione io vi ringrazio cmq vivamente.
Continuo a non essere d'accordo, amici miei. considerando che implementare la cache con ms application block ci vuole 2 minuti(quindi l'esempio di spendere giornate inutili di lavoro per implementarla la vedo un po esagerata, come anche spendere 1k , il vantaggio acquisito e' enorme a livello prestazionale e in termini di consumi di cpu e carico di lavoro al server db. quindi non implementarla a priori dove c'e la possibilita io lo vedo come uno spreco. Nella realta in cui lavoro non c'e una sola applicazione, ma ce ne sono a decine, e ne vengono create sempre di nuove. cosa succederebbe se dopo dieci applicazioni che ho scritto senza cache mi ritrovo il db zeppo di query inutili? signori dovete proprio convincermi. Io credo che prima di acquistare un db da 16 processori con tonnellate di ram, i programmatori dovrebbero iniziare a pensare meglio su come sviluppare i propri software.
Giovanni D'Arienzo
Nike
> ricordo che e' solo un discussione su un forum, chiedere e' lecito rispondere e' cortesia e visto il prolungarsi della discussione io vi ringrazio cmq vivamente
Chiedo scusa Giovanni, forse il mio intervento era di troppo in una discussione già conclusa. :-(
Credimi cmq sul fatto che il mio intento era solo di cercare di inserire uno spunto di ragionamento in più e niente altro. Sicuramente non affermo che la mia idea sia sicuramente quella giusta (credo valga lo stesso anche per Mauro), forse lo davo troppo per scontato ed è rimasto implicito.
I forum sono una importante risorsa sia per chi fa domande che per chi propone risposte (mi fa sicuramente piacere leggere la tua opinione e quella degli altri), purtoppo la discussione "asicrona" limita un pochino il confronto. Magari capiterà un'occasione di confronto a qualche evento. ;-)
Ciao e scusa ancora se sono apparso in qualche modo scortese nella precedente risposta.
Io personalmente adotto spesso un modello molto disconnesso con IOC
Faccio un esempio ho il mio
ICustomerService
che ha un po di metodi per ritornare i clienti, per modificare etc etc, un po in ottica TransactionScript, sotto ho una classe concreta che utilizza unDomain Model per fare l'operazione richiesta.
Nella UI uso un MVC il controller ha proprietà del tipo
public ICustomerService CustomerService {}get; set;
ed il motore di IoC lo popola con la classe concreta.
Se rilevo che ci sono problemi di prestazioni, posso con AOP dire, il metodo GetAllCustomers di ICUstomerService mettilo in cache per 60 minuti, ed ho un INterceptor di Castlke che gestisce la cache. Per cui la metto quando serve e solo se misurando mi rendo conto che serve veramente. L'unica accortezza è dire, mi faccio una architettura che mi permetta di inserire la cache senza piangere lacrime di sangue.
Alk
--Blog Eng: http://www.codewrecks.com/blogBlog Ita: http://blogs.ugidotnet.org/rgmTwitter: http://twitter.com/alkampfer
Io personalmente (e per esperienza) dico che la cache non serve ad abbattere il tempo di esecuzione delle query. Sql server dopo la prima esecuzione cacha molto bene. La cache serve a togliere il tempo necessario ad idratare le entity! Quindi a togliere tutta la parte e ciclo del reader per popolare l'oggetto che, in caso si trovi in cache, è bello e pronto.
Ovviamente in grandi numeri in cui non si può corazzare il db (nel mio caso mtv) la cache aiuta anche a reggere botta nei momenti di carico. Far scalare la cache è molto più facile e meno costoso di far scalare un db.
Concordo con Mauro e GianMaria che lasciarsi un entrypoint (tipo AOP con castle, spring o quel che vuoi) è un'ottima soluzione.
Ciauz
Ugo Lattanzi.NET Senior developer | Microsoft MVPhttp://imperugo.tostring.it
Giusta precisazione, non è tanto il non fare la query a sql la chiave, quanto reidratare le entità. In alcuni casi, in cui il codice fa una cosa tipo
CustomerService.GetAllCustomers
tipo per riempire le combo, e sono in una app winform che dialoga tramite wcf... la cache mi evita di fare la chiamata wcf, e quindi di passare per la rete, con un vantaggio indubbio.
alk.