<story><title>Reining in the thundering herd: Getting to 80% CPU utilization with Django</title><url>https://blog.clubhouse.com/reining-in-the-thundering-herd-with-django-and-gunicorn/</url></story><parent_chain><item><author>stingraycharles</author><text>Tangent, but I always had a different understanding of the “thundering herd” problem; that is, if a service is down for whatever reason, and it’s brought back online, it immediately grinds to a halt again because there are a bazillion requests waiting to be handled.&lt;p&gt;And the solution to this problem is to slowly, rate-limited, bring the service back online, rather than letting the whole thundering herd go through the door immediately.</text></item></parent_chain><comment><author>toast0</author><text>That&amp;#x27;s really not the traditional meaning of thundering herd, which is about waking up all the processes when a connection comes in, then they all try to accept it and it&amp;#x27;s a lot of work for nothing. You get much better results if only a single process is woken up for each event.&lt;p&gt;Your problem is a real problem though. Where I worked, we would call that backlog, and we would manage it with &amp;#x27;floodgates&amp;#x27; ... When the system is broken, close the gates, and you need to open them slowly.&lt;p&gt;In an ideal world, your system would self-regulate from dead to live, shedding load as necessary, but always making headway. But sometimes a little help is needed to avoid the feedback loop of timed out client requests that still get processed on the server keeping the server in overload.</text></comment>
<story><title>Reining in the thundering herd: Getting to 80% CPU utilization with Django</title><url>https://blog.clubhouse.com/reining-in-the-thundering-herd-with-django-and-gunicorn/</url></story><parent_chain><item><author>stingraycharles</author><text>Tangent, but I always had a different understanding of the “thundering herd” problem; that is, if a service is down for whatever reason, and it’s brought back online, it immediately grinds to a halt again because there are a bazillion requests waiting to be handled.&lt;p&gt;And the solution to this problem is to slowly, rate-limited, bring the service back online, rather than letting the whole thundering herd go through the door immediately.</text></item></parent_chain><comment><author>Ozzie_osman</author><text>Yea you are right. It could be a service being down and requests piling up, or a cache key expiring and many processes trying to regenerate the value at the same time, etc.&lt;p&gt;I think the article just used this phrase to describe something else. (Great article otherwise).</text></comment>