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

[Martin Cerdeira]

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

> 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.
>>
>
EDIT: Perdón, le di send sin querer...

 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. Esto es, minimizar las bajadas de la imagen orginal.

 2) Por otro lado, pueden haber transformaciones recurrentes (misma imagen,
mismos efectos) para eso, sería bueno guardar en cache los resultados pero,
capaz que sea mejor (corrijanme) que eso lo haga del lado del cliente.

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

Saludos!

-------------------------------------
Martín Cerdeira - Software Developer
At the end of the day, ship the fucking thing! It’s great to rewrite your
code and make it cleaner and by the third time it’ll actually be pretty.
But that’s not the point—you’re not here to write code; you’re here to ship
products. - Jamie Zawinski
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20130215/8ca058ac/attachment.html>