Old box, dumb code, few thousand connections, no big deal • Hacker News Board

Re: Old box, dumb code, few thousand connections, no big deal

#131

Post by earthboundkid » Fri, May 08, 2020, 3:40 AM UTC

bsder wrote: post #111

anonymoushn wrote: post #92

Earlier quoted context omitted.

I would prefer not to deal with "scaling up" for workloads that could run in a single process on commodity hardware. I've mainly worked at companies that would be bankrupt if they used Python the way Instagram does.

Django and Python somehow handled websites for entire newspapers on far wimpier hardware just fine --which makes me wonder if "cloud" (ie. non-deterministic memory and I/O accesses due to sharing with other tenants) isn't the problem rather than Python. You need a market. You need paying customers. You need cashflow. You need features. You need a business plan. You don't need scaling. Ever. To first, second and third…

Newspapers run everything behind a CDN, so Django isn’t a bottleneck. The things they do that can’t just be CDN buffered (like ad targeting and paywalls and comments) end up being supplied by outside vendors. I think Django fits well for a news org, but it’s good to understand why it fits well.

Re: Old box, dumb code, few thousand connections, no big deal

#132

Post by splintercell » Fri, May 08, 2020, 3:40 AM UTC

unnouinceput wrote: post #45

rantwasp wrote: post #41

should try this in erlang/elixir. i’m gonna bet you it could handle hundred of thousands of connections on a beefy machine (an million of connections w/ optimizations)

why tho? In real life if you're in need of handling millions of users per second, I bet you're already part of FAANG, at which point you simply open offices in each country and deploy local servers.

Doesn't WhatsApp story contradict to what you're saying? They handled millions of users per second, weren't part of FAANG and this helped them get acquired by FAANG and a high valuation for being a very nimble team and architecture.

Re: Old box, dumb code, few thousand connections, no big deal

#133

Post by rachelbythebay » Fri, May 08, 2020, 3:45 AM UTC

peterwwillis wrote: post #127

The premise is that people don't understand their system, or software, and need to be told how it works. So you have an admittedly ignorant person telling other ignorant persons that there are possibilities out there. That's... not really useful. What is useful is to spend 2 days researching massively concurrent network applications, and find the ones that were already written, and see how they evolved over time. For…

Yeah, I know, I'm terrible. I don't know jack about this stuff. I should just stop now while I'm behind. Clearly.

Re: Old box, dumb code, few thousand connections, no big deal

#134

Post by santoshalper » Fri, May 08, 2020, 3:46 AM UTC

flyinglizard wrote: post #108

bjt wrote: post #44

Whether intended or not, there's an undercurrent of "you're all so dumb for using Python" (or Ruby, or PHP, or other similarly performant language) here. I want to surface that and question it a bit. It's totally reasonable for a company to choose the Python/Gunicorn option if they already have a bunch of people who know Python and they don't need to serve tons of requests per second. Even if they do need to serve to…

The only reason to use Python for anything more than few hundreds lines worth of utility is if you're working on a codebase that's already in Python, and even then it's debatable. There simply isn't an excuse for using Python for any infrastructure. It does nothing particularly well - or even right - other than very purpose-specific scripting. It can tie things together well enough. And your codebase becomes a liabil…

So you always get downvoted to hell whenever you post this and you've decided everyone else is the problem? Can you even understand how you sound? I cringed with sympathetic embarrassment just from from reading this. Seriously, rethink your life choices man.

This coming from someone who has literally never written a line of python in his life.

Re: Old box, dumb code, few thousand connections, no big deal

#135

Post by robrtsql » Fri, May 08, 2020, 3:52 AM UTC

> Ever since I wrote about the whole Python/Gunicorn/Gevent mess a couple of months back, people have been asking me "if not that, then what". It got me thinking about alternatives, and finally I just started writing code.

I actually want to know: then what? As a web developer who usually reaches for Django or Flask with Gunicorn because I just don't know any better, is there a better stack that doesn't face these problems? Or is this a 'call to action' for somebody to build a better web server that follows this advice?

Re: Old box, dumb code, few thousand connections, no big deal

#136

Post by bibabaloo » Fri, May 08, 2020, 4:00 AM UTC

sytringy05 wrote: post #124

Compare this to the Enterprise platform I am dealing with on a current project, which has 4 x ec2 nodes with 8 CPUs and 32 Gb RAM. I can DoS it with a single java client running 50 threads. If I use 100 the p95 shoots up to 30 - 40 seconds. But the kicker is that no one (other than me) really cares. 50 concurrent threads is probably around the peak load it will get in prod, and various people involved think why bothe…

Honestly, I think that's what makes working at a large "web-scale" company so attractive to me. When you're running at that sort of scale you can't afford to be as apathetic about performance so there's a lot more engineering effort put into efficiency, because it makes financial sense to do so. OTOH, in a lot of enterprise type companies, you can be nothing more than a "feature monkey".

Re: Old box, dumb code, few thousand connections, no big deal

#137

Post by renatovico » Fri, May 08, 2020, 4:03 AM UTC

uvicorn with quart in python 3.7 handle a 800-1000 req/s in gke :) porting flask to quart take a 2 months of work

Re: Old box, dumb code, few thousand connections, no big deal

#138

Post by Rury » Fri, May 08, 2020, 4:09 AM UTC

Alupis wrote: post #85

Rury wrote: post #79

Earlier quoted context omitted.

>When you just slap things together and see if they work - are you really engineering? Why not? That's basically what testing is. Which was one of the attributes you attributed to "Engineer" >formal testing >I think we often cross "research and development" with "engineering" My general take: Scientists primarily focus on learning and proving new knowledge & ideas. (i.e. they research) Engineers focus in using proven…

Good points, but usually when we talk about testing in the realm of engineering, it's a means of verifying something is within the bounds it was designed for... not just to see what happens. We don't run test suites on our software to see what it does. We run test suites to validate it operates as it is supposed to. I think the way you described testing is more in line with tinkering and research rather than engineer…

>Good points, but usually when we talk about testing in the realm of engineering, it's a means of verifying something is within the bounds it was designed for... not just to see what happens.

Yeah that's fair.

I had originally skimmed the article, but after re-reading it the author apparently admits they didn't put any careful thought into what they made. No real goal. Just slapped stuff together so to speak. Which I'd agree doesn't quite sit as engineering to me...

Re: Old box, dumb code, few thousand connections, no big deal

#139

Post by Aeolun » Fri, May 08, 2020, 4:18 AM UTC

sytringy05 wrote: post #124

Compare this to the Enterprise platform I am dealing with on a current project, which has 4 x ec2 nodes with 8 CPUs and 32 Gb RAM. I can DoS it with a single java client running 50 threads. If I use 100 the p95 shoots up to 30 - 40 seconds. But the kicker is that no one (other than me) really cares. 50 concurrent threads is probably around the peak load it will get in prod, and various people involved think why bothe…

Oh man, don’t remind me. We have a bunch of GraphQL proxies in ECS that somehow cannot handle more than 5 connections each, so naturally the solution is to just spin up 19 more of them to get to 100 concurrent connections...

All of them sit at 1% cpu as well.

Re: Old box, dumb code, few thousand connections, no big deal

#140

Post by EdwardDiego » Fri, May 08, 2020, 4:19 AM UTC

29athrowaway wrote: post #125

rumanator wrote: post #46

Earlier quoted context omitted.

> Even if they do need to serve tons of requests per second, it's totally reasonable for them to still choose Python/Gunicorn if the cost of the additional servers is less than the cost of having to support multiple languages. How hard is it to get up to speed on any other tech stack? ASP.NET Core is extremely fast and the learning curve is close to none, for example. If someone was able to wrap his head around backe…

1) .NET APIs change very frequently. 2) C# is a very verbose language, that requires a lot of typing. 3) F#, the best language in .NET, is largely ignored by the .NET community.

I can't speak from recent experience, but on point 1) when I was teaching myself to code, I focused on .NET due to its prevalence in my local market. I took part in the .NET user group (called DUG, natch), attended the meetups etc.

And this was at the time when MS would announce a new blessed way to do things on a reasonably frequent basis. When I started, the blessed way to access data was DAOs, then it was ADO.NET (note, those could be around the wrong way, I have trouble figuring it out now in hindsight), then it was Linq2Sql, then that was deprecated for Entity Framework (which, I'll give credit, they seem to have stuck with, even if it does feel like a half-cribbed NHibernate).

I was frantically trying to learn the blessed thing, because the MS shops I was familiar with only used the blessed thing - the server was IIS, the database was SQL Server, the language was C# (I was the only member of the DUG who coded in F#, and few others knew of it), and you used the blessed patterns and the blessed frameworks.

Incidentally, this is why FOSS has had such a hard time in .NET, as soon as MS releases something that is reasonably feature complete, a lot of single-vendor minded companies switch to it.

And I met a lot of developers in their early 40s who were quietly terrified of getting left behind on the MS technology treadmill, and trying just as frantically to learn the new blessed thing as I was.

And then I got hired by a Java shop, and faced a paradigm where shit code cough java.util.Calendar, java.util.Date cough stuck around for yonks because it was good enough and replacing it had to be done very thoughtfully and gently.

Point #2 isn't super relevant in the age of IDEs, but I agree wholeheartedly that F# deserves a lot more love than it gets.