<div dir="ltr"><div dir="ltr">Buenas Javi,<div><br></div><div>Muchas gracias por tu respuesta. Respondo entre líneas,</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mar., 21 abr. 2020 a las 21:46, lasizoillo (<<a href="mailto:lasizoillo@gmail.com">lasizoillo@gmail.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mar., 21 abr. 2020 a las 20:37, J. Pablo Martín Cobos (<<a href="mailto:goinnn@gmail.com" target="_blank">goinnn@gmail.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><div>Alguno más se ánima al debate? </div><br></div></div></blockquote><div><br></div><div>Con las tareas asíncronas o en segundo plano como las llamas se pueden hacer virguerías. </div></div></div></blockquote><div><br></div><div>No es que lo llame yo... es por ejemplo como se define celery :-P</div><div><br></div>"Tasks can execute asynchronously (in the <b>background</b>) or synchronously (wait until ready)."</div><div class="gmail_quote"><br></div><div class="gmail_quote"><a href="http://www.celeryproject.org/">http://www.celeryproject.org/</a><br><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Aunque a veces eso de los timeouts se queda corto. Planteo un escenario:</div></div></div></blockquote><div><br></div><div>Los timeouts solo son un punto de todo lo planteado, si fueran lo único que hay que hacer sería el único punto ;-)</div><div><br></div><div><a href="https://goinnn.github.io/zen-of-high-load-and-high-availability-backend/index-es.html">https://goinnn.github.io/zen-of-high-load-and-high-availability-backend/index-es.html</a><br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Tengo un sistema de colas de trabajo que ataca a una pila de servicios externos, pongamos 40. Normalmente todo va como un tiro y se come muchos trabajos por segundo, pero por si acaso pongo un timeout de 5 segundos a las tareas. Si por debajo todo usa la misma cola, en plan configuración por defecto de celery, voy a llegar a un punto en el que todas las peticiones con timeout están haciendo de tapón y no dejando entrar a las que cuando entren irán rápidas porque no fallan. Al final hay un número de workers limitado y están mayormente ociosos esperando al timeout. Posibles soluciones:</div><div>- Segregar las colas de tareas en diferentes colas de mensajes. Las afectadas se encolarán por el tema de los timeouts y las otras seguirán yendo rápido como si nada pasase.</div><div>- El worker implementa el patrón circuit breaker y mientras dura la avería ese tipo de tareas se encolan a lo dead letters, se descartan o se ejecutan con un plan b que no implique el sistema afectado. Solo se producen timeouts hasta abrir el circuito, luego no se producen más timeouts.<br></div><div>- ??? (pon aquí la solución que se te ocurra, porque hay muchas formas de mejora)<br></div></div></div></blockquote><div><br></div><div>Totalmente, lo ideal son varias colas.... y es más varios workers. Dado que aunque tengas varias colas una cola puede llegar a bloquear a otra cola si está en el mismo worker (al menos en celery).</div><div><br></div><div>El propósito era tener una guía simple... sin profundizar. Ya que cuando más profundizas menos genérico es, y a un número más reducido de sistemas se puede aplicar.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div><br></div><div>Pero no siempre se puede dejar al usuario sin confirmación o hacer las cosas "en segundo plano". Si hay fallos de usabilidad puedes tener al usuario repitiendo la operación todo loco. Si le dices "tu operación estará en unos segundos" lo tendrás haciendo polling cada segundo. Es posible que si un caso de uso va regulero el usuario haga reintentos (como podría estar haciendo tu sistema de colas de trabajo con las tareas que te dan timeout) y haciendo que el sistema pase de regulero a muy malito. Para este tipo de cosas puede venir bien el concepto de "feature switching": lo que va regulero lo deshabilitas hasta que tengas el sistema sano otra vez.</div></div></div></blockquote><div><br></div><div>Totalmente de acuerdo, no siempre se puede... pero si la mayoría de los casos... por ejemplo nuestras a peticiones a tercero se hacen entorno al 90% en segundo plano. Y tan solo un 10% en primer plano (servidor web).</div><div><br></div><div>Aunque si que hay maneras de poder hacerlo siempre, aunque más complejas. Por ejemplo: si te comunicas con el backend a través de un socket... el primer plano podría decirle al segundo plano que hiciera X y cuando esté hecha el segundo plano podría responderle al frontend mediante dicho socket...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Por resumirlo en un rollo de esos zen:</div><div><br></div><div>- Lo que ahora va mal y en el instante siguiente va mal probablemente seguirá mal: ponlo en cuarentena y no vuelvas a intentarlo en un rato.</div><div>- Las cosas pueden fallar, pon barreras para que cuando se estropeen no te estropeen el resto. Por ejemplo usa diferentes colas para diferentes tipos de tareas.</div><div>- A veces es mejor dejar de hacer algo que hacelo mal, usa "feature switching" para esos momentos en los que las cosas no van finas.</div></div></div></blockquote><div><br></div><div>No conozco "feature switching" ¿tienes algún enlace al respecto?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Un saludo,</div><div><br></div><div>Javi<br></div></div></div>
_______________________________________________<br>
Python-es mailing list<br>
<a href="mailto:Python-es@python.org" target="_blank">Python-es@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-es" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-es</a><br>
</blockquote></div><div><br></div><div><br></div>Muchas gracias Javi!<div><br></div><div>Abrazo,<br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div style="font-size:12.8px">Pablo Martín Cobos</div><div style="font-size:12.8px">Ingeniero informático</div><div style="font-size:12.8px">Desarrollador Python/Django</div><div style="font-size:12.8px"><a href="tel:652%2053%2037%2036" value="+34652533736" style="color:rgb(17,85,204)" target="_blank">652 53 37 36</a></div><div style="font-size:12.8px"><a href="mailto:goinnn@gmail.com" style="color:rgb(17,85,204)" target="_blank">goinnn@gmail.com</a></div></div></div></div></div>