Newsgroup: it.lavoro.professioni.webmaster
Titolo: caching in asp

Ciao a tutti,
conoscete qualche sistema di caching delle pagine web /query sql da 
utilizzare con asp classico ?
Vale la pena di utilizzare un sistema di questo tipo ?
grazie
bye!
-- 
elimina unsampdoriano per rispondere via email

 
No, di contro ti posso consigliare (però in php) l'ottimo framework zend 
che tra le altre cose fa anche questo.
http://framework.zend.com/manual/en/zend.cache.html

 Vale la pena di utilizzare un sistema di questo tipo ?
Solo in condizioni *molto* estreme.
Come mai pensavi di utilizzare una soluzione così radicale (se posso 
chiedere)?
Sinceramente l'ho vista usare solo una volta, per un grosso e famoso 
portale con centinaia di migliaia di accessi al giorno.
Ciao,
Paolo

 chiedere)?
esplicita richiesta del cliente che mi ha chiesto di valutare 
fattibilità e convenienza.
Gli ho già fatto capire che non è cosa saggia, ma vorrei argomentare un 
po' più formalmente.


 po' più formalmente.
Bisognerebbe capire:
- perché te l'ha chiesto (il sito presenta problemi? è eccessivamente 
lento?);
- la "situazione" del sito di cui parlavo poc'anzi.
Ciao,
Paolo

 chiedere)?
Quelle che tu consideri situazioni 'molto estreme' sono la norma in 
tutti i piu diffusi progetti di una certa serietà e non mi pare che il 
cliente abbia chiesto niente di assurdo visto che tale modo di lavorare 
si trova anche in tutti i più diffusi applicativi open-source che si 
trovano in giro.
Questa è un ulteriore conferma di una mia personale opinione che l'asp e 
  tutti i progetti fatti in asp rappresentano il modo di lavorare sul 
web di 10 anni fa e, visto che si parla di nuove tecnologie, non è il 
caso che aggiunga altro.

 trovano in giro.
?
Cioè vuoi dirmi che tutti i progetti seri e quelli open source usano 
sistemi per fornire pagine statiche in cache invece delle corrispondenti 
dinamiche?
Puoi farmi qualche esempio?
Ciao,
Paolo

 - la "situazione" del sito di cui parlavo poc'anzi.
un negozio online che non ha milioni di visitatori giornalieri.


 non penso che su un db di qualche centinaio di prodotti
 > e con delle query che restituiscono una cinquantina
 > di righe si possa guadagnare molto
Decisamente no, sempre che indici e query siano impostati correttamente.
Ciao,
Paolo

Pablo Xon ha scritto:

Vorrei dire che oggi per fare un progetto serio si dovrebbe partire 
dall'architettura che deve essere robusta e fornire dei servizi di base 
essenziali a prescindere da cosa ci si vuole mettere sopra.
A questo proposito ad esempio microsoft ha rilasciato da tempo (per il 
suo framework .net) una serie di sorgenti (chiamate enterprise 
libraries) che vanno verso questa direzione e forniscono una serie di 
best practise su come iniziare un'applicazione di un certo spessore.
http://msdn2.microsoft.com/it-it/library/aa480453(en-us).aspx
per quanto mi riguarda le cose indispensabili in un applicazione di base 
sono:
autorizzazioni e autenticazioni
caching
accesso a db
passando al php sia il framework pear che zend hanno dei package che si 
occupano di caching di contenuto dinamico e tra i progetti open source 
che ne fanno uso mi vengono in mente ad esempio
http://www.sugarcrm.com
http://www.joomla.org
http://www.mediawiki.org
http://wordpress.org
http://drupal.org/
http://www.magentocommerce.com

 che ne fanno uso mi vengono in mente ad esempio
Ok, però cercavo un esempio concreto, un sito "reale" (un caso d'uso 
concreto, non un prodotto che poi può essere applicato in mille modi 
diversi) e, visto quanto ci siamo detti, che non sia in PHP (per i 
motivi visti sopra) o perlomeno che usi una cache del tipo di cui si 
parlava.
Per esempio in java l'unico che conosco (e ne ho visti parecchi, 
soprattutto in ambito bancario) è una parte di 
rossoalice.it
.
Stesso discorso in python: google (per dirne uno) lo usa massivamente ma 
non mi risulta che abbia un sistema di cache.
In .net non mi sembra che la situazione sia molto diversa, nonostante il 
fatto che un meccanismo di cache sia disponibile (es. antonveneta non lo 
usa, unicredit neanche).
Ciao, buona serata,
Paolo

 Paolo
Django lo usa:
http://www.djangoproject.com/documentation/
Dai una occhiata agli headers della risposta.
Tempo fa c'erano dei problemi, ma ora il caching viene effettuato 
correttamente.
Non so quanto sia raffinato, comunque.
Se ricordo bene, comunque, si tratta di settare semplicemente l'header 
Expires: xxx e Cache-Control: max-age=xxx "alla cieca" (secondo 
configurazione) e poi il resto degli headers (come Last-Modified) vengono 
generati di conseguenza dal sistema di caching.
Per l'OP, comunque, già cominciare a settare correttamente gli headers 
Last-Modified, Expires e Cache-Control può portare dei benefici, anche 
senza caching condiviso.
Manlio Perillo

 
http://www.djangoproject.com/documentation/
Sì, quando me lo son guardato lo scorso anno avevo visto che c'erano 
delle opzioni per la cache.
Il fatto è che il discorso che stavo facendo è un po' diverso 
(rileggendo il post di ieri vedo che effettivamente mi son spiegato in 
modo un po' contorto): non sto affermando che usare una cache sia 
inutile, ho semplicemente detto che l'ho vista usare in "casi estremi".
Nel senso che per velocizzare un sito è, se non l'ultima, perlomeno la 
penultima risorsa.
Prima ci sono:
- progettazione del db, delle chiavi e degli indici e uso di db engine 
performanti e personalizzabili (già qui di progetti "debolucci" ce ne 
sono a iosa);
- valutazione della tecnologia e dell'architettura da utilizzare (non 
per fare polemiche ma quanti CMS ci sono in PHP? E in Java? E in Python? 
Se un linguaggio/tecnologia è oggettivamente più potente e malleabile è 
esponenzialmente più improbabile trovarsi dentro a vicoli ciechi ed 
essere quindi costretti ad accrocchi, fork o riscritture del codice);
- progettazione del codice e del flusso dell'elaborazione (evitando 
inutili colli di bottiglia);
- scalabilità sia lato applicativo che di architettura;
- ottimizzazione del codice restituito (es. usare tre table annidate, 
con relativi css, quando basterebbero due div. Cosa vista giovedì scorso);
- utilizzo ponderato di risorse "pesanti" generate lato server (se 
fornisco un flash pesante occupo banda, se manipolo immagini sul server 
carico la macchina).
E altre 4-5 cose meno influenti.
Da dire che nel discorso non abbiamo neanche sfiorato l'aspetto sicurezza.
Inoltre la cache è utilizzabile solo in casi particolari, in cui ci sono 
molti utenti che accedono essenzialmente alle stesse pagine con gli 
stessi parametri/configurazione: se per assurdo (ma neanche tanto, ormai 
si va sempre di più nella direzione delle personalizzazioni spinte) ogni 
utente ad ogni accesso vedesse una pagina diversa, la cache 
rallenterebbe il sistema e il tempo di risposta (alla generazione del 
sorgente HTML si aggiungerebbe il tempo per il suo salvataggio, che 
essendo spesso su filesystem è sicuramente un collo di bottiglia), 
invece di aumentarlo.
Per questi motivi avevo parlato di "casi estremi": se si usa un sistema 
di cache per effettivo bisogno (quando tutti gli altri punti deboli son 
stati messi a punto) significa che si hanno milioni di utenti o 
applicazioni gargantuesche.
Poi si è ovviamente liberissimi di usarlo anche "solo" per ottimizzare 
piccoli siti, basta che non diventi una "scusa" per fare applicazioni 
coi piedi e poi cercare di salvare capra e cavoli (situazione che, per 
esperienza, ho visto molto, molto spesso anche in ambienti che 
dovrebbero essere "ultra-professionali").
Spero di aver chiarito meglio la mia precedente affermazione, scusate la 
prolissità ;)
Ciao,
Paolo

 [...]
Manlio Perillo

 "caching friendly".
Sul resto mi trovi abbastanza d'accordo, o comunque penso sia in buona 
parte questione di punti di vista ed esigenze specifiche.
Però questa tua frase non l'ho capita: in che senso il caching è "parte 
integrante" dell'HTTP?
Ciao,
Paolo

 Paolo
Manlio Perillo

 scalabili, in cui il caching riveste una parte importante.
Forse sono io ad essere un po' stanco ma questa tua frase non mi sembra 
il massimo della chiarezza... :)
Tralasciando che il REST è nato "un po'" (circa vent'anni) dopo l'http, 
però mi sembra scontato e quasi tautologico dire che un protocollo nato 
per il trasferimento di ipertesti è "scalabile": è nato apposta! :)
E il dubbio sul caching rimane: se parliamo di origini dell'HTTP e 
quindi di ipertesti questi erano documenti statici. La necessità (tutta 
da dimostrare, escludendo casistiche particolari, su questo insistevo) 
di rendere statici dei contenuti dinamici è comparsa molto, molto dopo.
Ciao,
Paolo

 Paolo
Manlio Perillo


Implementarlo lato client è banale.
Cmq capisco quello che vuoi dire, probabilmente agli albori di HTTP
nessuno pensava a pagine dinamiche, il web era nato per altri scopi.
Alcuni meccanismi come il "conditional get" forse (non ho tempo
di controllare :) sono arrivati con le revisioni successive del
protocollo.
Bye.
-- 
site 
http://passiomatic.com/
pics 
http://redpunk.com/
lnks 
http://del.icio.us/deelan

 Bye.
Manlio Perillo

 Non si tratta semplicemente di rendere statici dei contenuti dinamici.
No, ma il problema di fondo era questo.
Anche il discorso che facevo sulla "bassa 
personalizzazione/parametrizzazione utente" fa riferimento a queste 
premesse.
Ciao,
Paolo

 Paolo
Manlio Perillo

 cache-friendly.
Su questo siamo più che d'accordo.
Probabilmente per il tipo di applicazioni di cui mi occupo tendo a 
sottovalutare questa opportunità, ma continuo a essere convinto che non 
credo sia questo il problema principale nella lentezza della maggior 
parte delle applicazioni che si vedono in giro (sia proprietarie che 
libere) ;)
Ciao,
Paolo