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

[Martin Cerdeira]

2013/2/14 Andrés Gattinoni <andresgattinoni en gmail.com>

> 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.
>


Si, la verdad que es interesante Varnish por lo poco que estuve viendo. No
sé aún cómo se usa, pero suena copado y, me pondré a investigarlo, en la
medida que pueda, je!

Básicamente y para resumir, hay 2 problemas que involucran caches:

1) La aplicación en sí, tiene que guardarse las imagenes originales de
forma inteligente, para no estar yendo a buscarlas una y otra vez, si no
es
necesario


Hice algunos cambios menores:

- La estética del playground y al nombre de la app. Son boludeces,
obviamente, además tengo diseño gráfico -10
- Lo que comentaba del cache local, por medio de los headers que armo
cuando devuelvo el resultado, puntualmente "Cache-control: public;
max-age=28800"
 Luego será cuestión de ir jugando con el max-age...
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20130215/828a00e5/attachment.html>