Live data from Hacker News

Reining in the thundering herd: Getting to 80% CPU utilization with Django

blog.clubhouse.com

11–20 of 139 posts

Re: Reining in the thundering herd: Getting to 80% CPU utilization with Django

#11
post #5

Performance is the only thing that is holding me back to consider Python for bigger web applications. Of the 3 main languages for web dev these days - Python, PHP and Javascript - I like Python the most. But it is scary how slow the default runtime, CPython, is. Compared to PHP and Javascript, it crawls like a snake. Pypy could be a solution as it seems to be about 6x faster on average. Is anybody here using Pypy for…

Clubhouse is using CPython

Re: Reining in the thundering herd: Getting to 80% CPU utilization with Django

#13
post #5

Performance is the only thing that is holding me back to consider Python for bigger web applications. Of the 3 main languages for web dev these days - Python, PHP and Javascript - I like Python the most. But it is scary how slow the default runtime, CPython, is. Compared to PHP and Javascript, it crawls like a snake. Pypy could be a solution as it seems to be about 6x faster on average. Is anybody here using Pypy for…

The top 5 web app programming languages by market share are PHP, Java, JS, Lua and Ruby.

Re: Reining in the thundering herd: Getting to 80% CPU utilization with Django

#14
post #7

Earlier quoted context omitted.

So much this. Practically any other option is better than Python for web development if you're looking for performance.

By this logic, why not Java, C++, Rust, Go, C#? They’re all web-capable and blow the doors off PHP, Python, etc.

C#, Java, C++ need application servers, no?

"Serverless" scales infinitely due to its simpler request/response lifecycle.

Re: Reining in the thundering herd: Getting to 80% CPU utilization with Django

#15
post #11
post #5

Performance is the only thing that is holding me back to consider Python for bigger web applications. Of the 3 main languages for web dev these days - Python, PHP and Javascript - I like Python the most. But it is scary how slow the default runtime, CPython, is. Compared to PHP and Javascript, it crawls like a snake. Pypy could be a solution as it seems to be about 6x faster on average. Is anybody here using Pypy for…

Clubhouse is using CPython

Interesting. Is there a reason for this?

Re: Reining in the thundering herd: Getting to 80% CPU utilization with Django

#16
post #13
post #5

Performance is the only thing that is holding me back to consider Python for bigger web applications. Of the 3 main languages for web dev these days - Python, PHP and Javascript - I like Python the most. But it is scary how slow the default runtime, CPython, is. Compared to PHP and Javascript, it crawls like a snake. Pypy could be a solution as it seems to be about 6x faster on average. Is anybody here using Pypy for…

The top 5 web app programming languages by market share are PHP, Java, JS, Lua and Ruby.

...said a stranger on the internet without any sources to back up this claim.

Re: Reining in the thundering herd: Getting to 80% CPU utilization with Django

#17
post #4

If it is just a backend, why not port it over to one of the myriad of cloud autoscaling solutions that are out there? The opportunity cost of spending time figuring out why only 29 workers are receiving requests over adding new features that generate more revenue, seems like a quick decision. Personally, I just start off with that now in the first place, the development load isn't any greater and the solutions that a…

They are on a back-end that does auto-scaling. They stated that they had problems when scaling up past 1000 nodes.

Now, maybe they could have fixed that issue instead, but going from 29 to 58 workers is easy, it's not the same going to 29,000 to 58,000. And 1000 hosts vs 500 is a non-trivial cost.

Re: Reining in the thundering herd: Getting to 80% CPU utilization with Django

#18
post #4

If it is just a backend, why not port it over to one of the myriad of cloud autoscaling solutions that are out there? The opportunity cost of spending time figuring out why only 29 workers are receiving requests over adding new features that generate more revenue, seems like a quick decision. Personally, I just start off with that now in the first place, the development load isn't any greater and the solutions that a…

containers would've solved it

one process per container, easy peasy

Re: Reining in the thundering herd: Getting to 80% CPU utilization with Django

#19
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.

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.

Re: Reining in the thundering herd: Getting to 80% CPU utilization with Django

#20
post #4

If it is just a backend, why not port it over to one of the myriad of cloud autoscaling solutions that are out there? The opportunity cost of spending time figuring out why only 29 workers are receiving requests over adding new features that generate more revenue, seems like a quick decision. Personally, I just start off with that now in the first place, the development load isn't any greater and the solutions that a…

Author here. We do and did use autoscaling heavily but at a certain scale we just ran out of headroom on the smaller instance types we were using. Jumping to a much larger instance types meant that we will likely never run into those headroom issues again, plus solves other problems like faster spin up, better sidecar connection pooling and allows for a much higher hit rate on per instance caching.
Post reply on HN