[Py-ES] Sistemas de colas

[Nekmo]

Para nada ha sido pedante o chapas Lasizoillo, es genial contar con
comentarios tan completos y tan bien documentados, ¡gracias! :)

Nunca me había parado a mirar sobre extender Celery, y ahora ya sé por
dónde empezar. Por curiosidad, ¿para qué habéis tenido la necesidad de
ampliarlo?

En mi caso uso Celery por los mismos motivos, ya que se adapta a las
necesidades de cualquier proyecto sin necesidad de conocer todos sus
requerimientos. Además, al usarlo en más proyectos, adquiero conocimiento
reaprovechable. Otra ventaja es su robustez, su documentación y añadiría su
monitorización. Es importante monitorizar el correcto funcionamiento de las
colas, y para Celery al ser tan utilizado hay muchos recursos.

Un cordial saludo:
-- Nekmo.

Sitio web: http://nekmo.com
Dirección de contacto: contacto at nekmo.com
XMPP/Jabber: contacto at nekmo.com
Google+: Nekmo Com


El mar, 6 jul 2021 a las 8:17, Federico Mon (<gnu.fede at gmail.com>) escribió:

> Es un buen apunte, yo no he trabajado con procesos que consumiesen tanta
> RAM
>
> On July 5, 2021 11:12:24 PM GMT+02:00, Jose Manuel <jakermater at gmail.com>
> wrote:
>>
>> Quería señalar que si te quedas sin RAM y el trabajo está ya lanzado, si
>> te quedas sin el.
>>
>> Y aunque hagas try, except finally. Al ser matado por el sistema no lo
>> captura ni el try ni sentry.
>>
>> Hablo de creación de ficheros de más de 10GB .
>>
>> Y lo resalto porque bueno, parece obvio cuando ya lo sabes, pero cuando
>> no, te pegas de leches con los try except...
>>
>> El lun., 5 jul. 2021 22:41, Federico Mon <gnu.fede at gmail.com> escribió:
>>
>>> Yo he usado Celery (poco) y Redis Queue (algo más) y me quedo con este
>>> último.
>>>
>>> En general, no tengo la experiencia de que se mueran los workers. Los
>>> trabajos pueden fallar, si salta alguna excepción, etc, pero con un Sentry
>>> o similar puedes estar al tanto.
>>>
>>> Creo que en tu caso sería levantar tantos workers como cores tengas, y
>>> así no te excedes con los trabajos simultáneos. Quizás meterlo bajo un
>>> supervisor para asegurarte de que no mueren?
>>>
>>> On July 5, 2021 9:30:25 PM GMT+02:00, Felipe Maza <felipe at felipem.com>
>>> wrote:
>>>>
>>>> Hola,
>>>>
>>>> Llevo unos días viendo diferentes programas para gestionar sistemas de
>>>> colas y, en principio, creo que casi todos parecen complejos para lo que
>>>> necesito.
>>>>
>>>> Mi problema a resolver es el siguiente, tenemos un modelo de predicción
>>>> que se ejecuta periódicamente y también bajo demanda del usuario. Ese
>>>> modelo se ejecuta en un solo hilo y tarda bastantes minutos en completar la
>>>> tarea. Por tanto, puedo tener varias ejecuciones simultáneas siempre que no
>>>> excedamos el número de cores disponibles, ya que en ese caso se vuelve el
>>>> sistema excesivamente lento. Al modelo se le invoca a través de una pequeña
>>>> api hecha con flask. En el futuro puede que haya otros modelos en la
>>>> misma máquina.
>>>>
>>>> Hace un par de años para un problema similar ya me programé mi propio
>>>> gestor de colas rudimentario,pero ahora busco algo que sea estable, con
>>>> pocos bugs, mantenible, etc.
>>>>
>>>> Las características que (creo que) necesito son:
>>>> - Encolar tareas (logicamente)
>>>> - Tener colas con diferente prioridad (manuales, periódicas).
>>>> - Registrar la salida, tanto si ha tenido éxito como si ha tenido
>>>> errores.
>>>> - (opcional) En un futuro ejecutar otras apis con modelo en la misma
>>>> máquina.
>>>>
>>>>
>>>> Lo primero que he explorado ha sido Celery, y es impresionante el
>>>> montón de posibilidades que ofrece, tantas que ir poco más de los ejemplos
>>>> iniciales me parece muy complejo para solucionar el problema anterior. Me
>>>> da la sensación que hay que controlar un montón de aspectos para montarlo y
>>>> mantenerlo correctamente; y que cuando aparezca algún error no va a ser
>>>> rápido dar con la solución.
>>>>
>>>> Después de mirar otras alternativas, con la que parece que he montado
>>>> una primera versión que parece que me lo soluciona, es Redis Queue (
>>>> https://python-rq.org/). La forma en la que utiliza Redis es
>>>> relativamente simple, y más o menos ofrece lo que necesito.
>>>> En el tema de los worker creo que ahí flojea un poco, pues parece que
>>>> tendré que gestionar manualmente cuántos hay arrancados y si no se han
>>>> muerto.
>>>>
>>>>
>>>> ¿Tenéis experiencia resolviendo algún problema similar? ¿Creéis que
>>>> merece la pena el esfuerzo para aprender celery (u otra solución) para
>>>> algo que no debería ser muy complejo? ¿Redis os parece buen motor o
>>>> debería ir a Rabbitmq? Nunca había usado ninguno de ellos. ¿Cómo
>>>> gestionais el tema de los worker? Seguro que es más sencillo de lo que
>>>> creo.
>>>> Cualquier comentario que queráis hacer será bienvenido.
>>>>
>>>> Gracias,
>>>>
>>>> Un saludo.
>>>>
>>> _______________________________________________
>>> Asociación Python España: http://www.es.python.org/
>>> general mailing list
>>> general at lists.es.python.org
>>> https://lists.es.python.org/listinfo/general
>>>
>> _______________________________________________
> Asociación Python España: http://www.es.python.org/
> general mailing list
> general at lists.es.python.org
> https://lists.es.python.org/listinfo/general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.es.python.org/pipermail/general/attachments/20210707/60e8a5f1/attachment.htm>