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

Martin Cerdeira martincerdeira en gmail.com
Mie Feb 13 15:39:46 ART 2013


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

> On Wed, Feb 13, 2013 at 12:23 AM, Martin Cerdeira <
> martincerdeira en gmail.com> wrote:
>
>> Memory behavior<https://devcenter.heroku.com/articles/dynos#memory-behavior>
>>
>>> Each dyno is allocated 512MB of memory to operate within. Most
>>> applications will fit comfortably within this allowance, and as a developer
>>> you need not worry about memory at all.
>>> Fuente: https://devcenter.heroku.com/articles/caching-strategies
>>>
>>> Cada dyno es una instancia de la aplicación. Como la cuenta es gratis,
>>> tengo 1 dyno, así que mi RAM es: 512 * 1 = 512
>>>
>>> XD
>>>
>>>
> Mi comentario igual iba por el lado de la seguridad de la aplicación.
> Capaz el manejo que hace Heroku de la memoria le permite que si uno de tus
> scripts la lima mal, te deje de andar a vos y no joda a nadie más, pero
> incluso en ese caso entiendo que tendrías problemas para atender a otros
> clientes. Imaginate que por ignorancia o por maldad te paso una imagen muy
> grande (no sé, 100MB, 1 GB): cómo responde la aplicación? Ahí creo que hay
> dos cuestiones a considerar (que se pueden complementar):
> 1) hasta dónde leés el archivo original para que tu proceso no se quede
> colgado (para esto yo usaría dos cosas: el Content-Length que te da urllib
> al consultar el objeto que te vas a bajar, y para mayor seguridad, pondría
> un límite de bytes al hacer el read()),
> 2) qué hacés con lo que leíste: ahí es donde tenés que considerar si te
> conviene guardarlo en memoria con StringIO o mandarlo a un archivo... pero
> creo que si ponés el límite en el punto 1, esto ya no calienta
>
> Sobre el tema del cache, si no entiendo mal (no ví esta parte del código),
> con un dict la limitación que vas a tener es para que dos requests, que
> corran en procesos diferentes, accedan al mismo cache. Si no querés usar el
> disco, memcached puede ser una buena opción y fácil de implementar porque
> se maneja también como un diccionario. Por otro lado, si usás un framework
> como Django (y cualquier otro seguro que tiene también), podés usar sus
> librerías de cache para que si el día de mañana necesitás cambiar el
> backend de tu cache sea más fácil.
>
> Saludos,
>

Si, tal cual, si me pasás una imagen muy grande, actualmente se está yendo
al diablo =). No encaré nada (aún) al respecto pero, seguramente algún
límite de tamaño vaya a poner, y también es probable que use el header
Content-Length, como vos mencionaste.

Con respecto al cache, basicamente el dict() que puse ahora no es aplicable
a un escenario real, lo puse para tener algo rapido y no dejarlo sin
ninguna cache, hasta que me decida que hacer. Por supuesto que con el dict
tengo la limitación que me comentabas, tampoco puedo manejar cuando expira,
etc, etc.

Saludos!!!
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20130213/5a590e6b/attachment.html>


More information about the pyar mailing list