<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Hi, Maxim, and thanks for the feedback.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">My approach is to monitor the downstream NGINX server, whereas I think that your approach points at monitoring the upstream Gunicorn, isn't it? If so, then yes, that's another way to do it. I have never checked whether Gunicorn (in my particular case) offers that information, but it would definitely be one way to do it.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Anyhow, I still would love to be able to query NGINX for much more information about active requests and upstreams but, unfortunately, I cannot be of much help with the internals of NGINX.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Thanks.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Aug 21, 2025 at 4:05 PM Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<br>
On Thu, Aug 21, 2025 at 09:38:16AM +0200, Jaume Sabater wrote:<br>
<br>
> Related to the information provided by NGINX via stub_status, I would like<br>
> to suggest implementing ways to get feedback on the upstream servers, so<br>
> one could figure out when they are done with requests and updates on the<br>
> upstream node can start again.<br>
> <br>
> For example, let's say I have an upstream "myapp" with two servers, "<br>
> <a href="http://myapp1.domain.com" rel="noreferrer" target="_blank">myapp1.domain.com</a>" and "<a href="http://myapp2.domain.com" rel="noreferrer" target="_blank">myapp2.domain.com</a>". I add the "down" option to the<br>
> first one and reload. Then I have to wait for the server to finish off<br>
> processing requests to that first server before deploying the new version<br>
> of the "myapp" application. Once completed, I need to remove the "down"<br>
> option, add it to the other server, then reload. Not sure if this is the<br>
> expected way to do things, of course, but right now I need to play with<br>
> console tools to check for connections, which is not as reliable as having<br>
> NGINX inform about, say, they number of active requests with "<br>
> <a href="http://myapp1.domain.com" rel="noreferrer" target="_blank">myapp1.domain.com</a>".<br>
<br>
Thanks for the input.<br>
<br>
With reloads, I don't think implementing this would be trivial and <br>
can be done efficiently, as this information needs to be collected <br>
and updated in shared memory.  Even when using upstream shared <br>
memory zones, since these are recreated on configuration reloads, <br>
so the new worker processes don't have access to data of old <br>
upstream servers.<br>
<br>
Just in case, the most simple approach for the particular use case <br>
would be to monitor old worker processes - and when they are all <br>
done, you can be sure the upstream server in question is no longer <br>
used.  This should work even if the same server is used elsewhere, <br>
and you cannot rely on checking connections and/or status of the <br>
upstream server itself.<br>
<br>
-- <br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer" target="_blank">http://mdounin.ru/</a><br>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Jaume Sabater<br>"Ubi sapientas ibi libertas"</div></div></div>