2010-05-02 13 views
9

L'unica ragione per cui posso pensare è che il calcolo di ETag potrebbe essere costoso. Se le pagine cambiano molto rapidamente, è probabile che la cache del browser venga invalidata dallo ETag. In tal caso, calcolare lo ETag sarebbe una perdita di tempo. D'altra parte, una risposta di tipo 304 quando possibile riduce al minimo la quantità di tempo trascorso nella trasmissione. Quali sono alcune buone linee guida per quando lo ETag rischia di essere un vincitore netto se implementato con Django CommonMiddleware?Qualche motivo per non utilizzare USE_ETAGS con CommonMiddleware in Django?

risposta

-2

Non capisco perché stai cercando una ragione per non fare qualcosa. Tuttavia la tua analisi è lungi dall'essere completa: le richieste condizionali/304 risposte possono effettivamente rendere la tua applicazione molto più lenta di quanto farebbe se togliessi l'if-modified-since/if-none-match, tuttavia mantengono i motori di ricerca felici e sono vantaggiosi con Replication Server-server (ad esempio su CDN)

C.

+4

Questa risposta non è molto utile per diversi motivi: 1) La seconda frase contiene diverse idee che potrebbero essere suddivise in diverse frasi. 2) Perché non dovrei cercare una buona ragione per non fare qualcosa? 3) dichiari che 304 risposte possono rendere le cose più lente senza spiegare perché. Mentre tu hai menzionato qualcosa sull'uso di if-modified-since (non so come si applica a ETag) e se non c'è nessuna corrispondenza, ma questa non è una gran spiegazione. 4) "mantengono i motori di ricerca felici"? Intrigante, ma estremamente vago. – allyourcode

4

Come con qualsiasi meccanismo di caching, sarà necessario valutare il trade-off tra il tempo trascorso manipolare la cache e larghezza di banda salvato a causa di esso.

Come dici tu, se la risposta sta cambiando spesso, ETags potrebbe non essere molto utile. Gli ETag sono un metodo per memorizzare tutte le risposte nella cache, quindi se la risposta cambia spesso non viene in realtà memorizzato nella cache. Tuttavia, suppongo che dal momento che gli ETag sono di uso comune, le implementazioni dei browser sono in modo risonabile velocemente e probabilmente anche Django è abbastanza veloce.

Forse ci sono altre aree prima della risposta che potrebbero trarre vantaggio dalla memorizzazione nella cache con, ad esempio, memcached.

Ancora una volta, sarà utile provare a profilare questo con i tuoi dati reali piuttosto che generalizzare a "fare o non usarlo".

0

Ci sono molti modi per gestire la cache, ed è spesso specifica applicazione, propongo nei primi scenari come si potrebbe considerare l'utilizzo USE_ETAGS da django.middleware.common.CommonMiddleware:

  1. dividere la vostra applicazione tra cacheable e gunicorn non-cacheable le istanze. Collega il sito al proxy inverso. Quindi continuare con,

  2. Scrittura del codice che invalida la cache sui salvataggi del modello. Come passaggio successivo,

  3. Scrivere il proprio middleware di memorizzazione nella cache personalizzato.

Problemi correlati