Gracias por vuestras respuestas, Por ahora me quedaré con Redis Queue pero sí que habrá que ir viendo poco a poco el tema de celery.
Un saludo, El mié, 7 jul 2021 a las 0:30, Nekmo (<conta...@nekmo.com>) escribió: > 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: conta...@nekmo.com > XMPP/Jabber: conta...@nekmo.com > Google+: Nekmo Com > > > El mar, 6 jul 2021 a las 8:17, Federico Mon (<gnu.f...@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 <jakerma...@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.f...@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 <fel...@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 >>>> gene...@lists.es.python.org >>>> https://lists.es.python.org/listinfo/general >>>> >>> _______________________________________________ >> Asociación Python España: http://www.es.python.org/ >> general mailing list >> gene...@lists.es.python.org >> https://lists.es.python.org/listinfo/general >> > _______________________________________________ > Python-es mailing list > Python-es@python.org > https://mail.python.org/mailman/listinfo/python-es > -- Felipe Maza Fernández fel...@felipem.com 622 338 121
_______________________________________________ Python-es mailing list Python-es@python.org https://mail.python.org/mailman/listinfo/python-es
