[pyar] Tengo una idea, tengo una idea??

[Andrés Gattinoni]

2013/2/13 Martin Cerdeira <martincerdeira en gmail.com>

> 2013/2/13 nachopro <tranceway en gmail.com>
>
>> 2013/2/12 Martin Cerdeira <martincerdeira en gmail.com>:
>> > En cuanto a cachear, la versión actual tiene un caching «de juguete» q
>> es,
>> > básicamente un dict()  donde la key es la url a la imagen... Obviamente
>> esto
>> > es provisorio!!!
>> > Acá abro un paréntesis para preguntar q usarían uds?? Yo tenía pensado
>> usar
>> > algo parecido a lo q tengo ahora (un dict en memoria) porque no quiero
>> tener
>> > q escribir en el disco (algo cómo memcache) uds q opinan???
>> > Saludosssss
>>
>> Buenas che, estuve viendo y es basante pintón el proyecto!
>> Veo que vos cacheás la imagen provista pero no el resultado. Pienso
>> que deberías tener dos cachés: imágen original e imágen producida. Acá
>> deberías definir una expiración: Por ejemplo, si alguien usa tu
>> servicio para tu web, en su avatar o similar, no te calienta tanto
>> tener el caché de la imágen original y sí, en cambio, la de la imagen
>> producida para no usar recursos de gusto.
>>
>> Con el tema de la caché en concreto deberías evaluar el backend
>> (memcache, redis, etc), cuánto podés alojar, cuándo descartar un
>> caché, etc etc etc. No creo que te convenga pasarte a Django sólo por
>> su sistema de caché como comentan en otro mail.
>>
>> Saludos
>>
>
> Exacto, ahora solo cacheo la imagen original, para ahorrarme ir a
> buscarla, pero, es muy buena idea lo que vos me comentás de cachear el
> resultado, por si el request del mismo efecto sobre la misma imagen se
> torna reiterativo.
>

Ah! Eso me pasa por no mirar bien el código, pero sí, yo me refería a
cachear el resultado (que además estaría vinculado al dato de la URL de la
imagen original).


>
> Con respecto a lo de Django, pienso lo mismo que vos =D
>

Sí, yo estoy de acuerdo. Mi comentario sobre Django fue porque en algún
punto del thread se habló de usar algún otro framework como Django o Flask.
Entonces, si usaras otro framework para hacer otras cosas, podrías
aprovechar el motor de cache.

Pero también es una muy buena idea dejar que el servidor HTTP maneje el
cache. Además de Varnish, también Nginx te puede servir para hacer cache (y
de servidor web en general).
Eso te obligaría a una buena práctica, que sería mandar bien los headers de
cache de tu respuesta HTTP para que los pueda interpretar el proxy que
estés usando.

El único potencial problema que le veo es que establece una mediación entre
tu aplicación y el cache, y si en algún escenario vos necesitaras tener un
control directo desde tu aplicación sobre ese cache (por ejemplo, para
borrarlo o actualizarlo en función de reglas del negocio), te verías
obligado a hacer algunas chanchadas o cambiar la forma de cachear.
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20130214/e4adcd88/attachment.html>