2012-05-03 9 views
10

Me sorprende que no vea nada más que "usar apio" al buscar cómo usar las tareas de apio con sorl-thumbnails y S3.¿Punteros sobre el uso de apio con sorl-thumbnails con almacenamientos remotos?

El problema: el uso de almacenamientos remotos provoca demoras masivas al generar miniaturas (piense en más de 100 páginas en una página con muchas miniaturas) mientras el motor de miniaturas descarga originales del almacenamiento remoto, los comprime y luego los carga nuevamente en s3.

¿Dónde es un buen lugar para configurar la tarea de apio dentro de sorl, y a qué debo llamar?

Cualquiera de sus experiencias/ideas sería muy apreciada.

Comenzaré a cavar alrededor de las partes internas de Sorl para encontrar un lugar más útil para retrasar esta tarea, pero hay algunas cosas más que me preocupan si esto se ha resuelto antes.

  1. ¿Qué imagen se devuelve inmediatamente? A Sorl se le debe decir de alguna manera que la imagen devuelta no es la miniatura real. La memoria caché debe invalidarse cuando el apio finaliza la tarea.

  2. manejar múltiples peticiones de generación de miniaturas de forma inadecuada (sólo es necesario la primera para una clave dada caché)

Por ahora, he resuelto temporalmente mediante el uso de un proxy caché nginx que puede servir éxitos inversa mientras que el backend dedica tiempo a generar páginas costosas (cambio de tamaño de PNG enormes en una gran rejilla de producto), pero es un proceso muy manual.

+0

http://djangosnippets.org/snippets/1562/ podría ayudar – jpic

+0

@jpic gracias, pero eso es 3 años de edad - ya funciona con almacenes remotos. Lo que necesito ayuda es la generación asíncrona de miniaturas de almacenamiento remoto ... –

+0

@YujiTomita ¿Has tenido algún progreso con esto? Sería bueno escuchar tus descubrimientos. – jamesc

Respuesta

3

Creo que lo que quiere hacer es establecer THUMBNAIL_BACKEND en una clase personalizada que anula el método _create_thumbnail. En lugar de generar la miniatura en esa función, se inicia una tarea de apio que llama a _create_thumbnail con los mismos argumentos dados a la función. La miniatura no estará disponible durante la solicitud, pero se generará en segundo plano.

3

Según tengo entendido, Sorl funciona correctamente con el almacenamiento S3 pero es muy lento.

Creo que sabe qué tamaño de imagen necesita.

Debe iniciar la tarea de apio después de cargar la imagen. En la tarea a la que llama al sorl.thumbnail.default.backend.get_thumbnail(file, geometry_string, **options)

Sorl generará una miniatura y la cargará en S3. La próxima vez que solicite una imagen de la plantilla, ya está almacenada en caché y servida directamente desde los servidores de Amazon

una manera limpia de manejar una imagen en miniatura del marcador de posición mientras se procesa la imagen.

Para esto, tendrá que anular el servidor de Sorl. Agregue un nuevo argumento a la función get_thumbnail, p. generate=False.Cuando va a llamar a esta función desde el paso por el apio generate=True

Y en cambio de función que es la lógica, por lo que si el pulgar no está presente y generate es True se trabaja igual que el back-end estándar, pero si generate es falso devuelve su imagen del placeholder texto como "Procesamos su imagen ahora, vuelva más tarde" y no llame al backend._create_thumbnail. Puede iniciar una tarea en este caso, si cree que la miniatura se puede eliminar accidentalmente.

espero que esto ayude a

2

Puede utilizar Sorlery. Combina sorl y apio para crear miniaturas a través de los trabajadores. Es muy cuidadoso de no hacer ningún acceso al sistema de archivos fuera del hilo de trabajo.

La miniatura devuelta inmediatamente (antes de que el trabajador haya tenido la oportunidad) se puede controlar configurando THUMBNAIL_DUMMY_SOURCE en un marcador de posición apropiado.

El trabajo se crea la primera vez que se solicita la miniatura, las solicitudes subsiguientes se sirven en la imagen ficticia hasta que finaliza el subproceso trabajador.

+0

comentario largo vencido: esto se ve fantástico. Muchas gracias! Lo verificaré tan pronto como mi próximo proyecto. Este ha sido el mayor cuello de botella con el uso de almacenamientos remotos. Los desafíos de ingeniería añadidos al usar almacenamientos remotos con el ecosistema django frente a los obstáculos de las operaciones se resolvieron al tener servidores de aplicaciones verdaderamente independientes. –

+0

Aunque este fue un experimento interesante, creo que debería usar algo como Cloudinary o Imgix. – Aidan

Cuestiones relacionadas