Live data from Hacker News

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

rachelbythebay.com

211–220 of 288 posts

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

#211
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…

I don't really get what the point of this post is. Is it really a dig at python? Python can handle thousands of connections in a single thread no problem with basic enough stuff. Is what the author did supposed to be impressive? Is it supposed to make python look bad? I don't get it. Seems like run of the mill stuff. Python might struggle at the same level of concurrency (was it like 15k?) but you can still do 10k co…

I made a post some time back about maintaining 64k connections in a Ruby process a while back: https://www.wjwh.eu/posts/2018-10-29-double-hijack.html . It only stopped at 64k because I could not be bothered to rig up multiple IPs so it eventually ran out of ports.

Just having a lot of connections that do trivial stuff is not very difficult. It becomes way more interesting when all of those connections need to access shared data structures and whatnot.

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

#212
post #61

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…

> How hard is it to get up to speed on any other tech stack? If I find myself debugging python tools, I usually just add debug statements to figure out WTF it is trying to do, and reimplement it in bash. It invariably is less than 10% as many lines of code, and also more debuggable / readable than the original. Granted, most of the python scripts I see these days are build processes or cluster coordinators.

Given how badly bash goes wrong if spaces in filenames sneak in, or if you want to do error handling, at several places I've had a policy of rewriting scripts from bash into python. It has the advantage that it's usually a better cross-platform solution than running bash on Windows.

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

#213

Earlier quoted context omitted.

As we've seen in the cloud costs thread, going from python on AWS to Rust on dedicated hardware can push your bills from 30'000$/month down to 300$/month, which more than pays for the dev salaries (especially if you're not paying the excessive and unnecessary salaries of the bay area)

How many hours would you expect that rewrite to take when done by Python developers learning Rust as they do it? And what's the opportunity cost of the new features they can't create because they're rewriting existing apps? If you're arguing that Python has more runtime overhead than Rust, I don't disagree. But there's a reason people invented higher level languages than C. Rust is a far nicer systems language than C…

It is not clear that Rust can be as fast to develop in as Python or Kotlin, for the typical run of coders--people using Rust now are mostly well above average--but it is abundantly clear that, supported by good libraries, modern C++ can. Faster would be a tall order, but is not necessary.

Put in the same effort, and get 10x-1000x faster code or lower resource needs. Why not?

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

#215
post #50

Rachel presumably wrote her server in a reasonable language like C++ (though I don't see a link to her source), but when I wrote httpdito⁰ ¹ ² I wrote it in assembly, and it can handle 2048 concurrent connections on similarly outdated hardware despite spawning an OS process per connection, more than one concurrent connection per byte of executable†. (It could handle more, but I had to set a limit somewhere.) It just…

> I feel like with modern technologies like ... we ought to be able to do a lot of things that we couldn't even imagine doing in 2005... As a self-taught programmer I would say that what all these less efficient bit easier to learn technologies have done is enable people like me who evidently are not geniuses like yourself to write software. Should programming always be an ivory tower thing?

I think part of the point of this is that this approach isn't particularly complicated (writing in assembly is unecessary, but everything else described in both the article and the comment above is basically the simplest way to make a webserver).

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

#216
post #180

Earlier quoted context omitted.

I’m most comfortable in .net core but I recently learned Django because I kept hearing how productive it was from HN and all the startups around me use it, but Im starting to feel like I chose to move the wrong way. I will say I like how Postgres is the default for python and the library situation is much better over there as well.

I've tried working with Django and it's always seemed much too heavyweight to me. Flask is my preferred web framework for Python; much easier for me to use and feels like it's helping me where needed and getting out of my way where needed, not weighing me down.

Django is very good if you want your end-site to be "CMS like". It comes will a lot of accessories to help in that goal.

Flask is lighter and it is more DIY but easier if you have something that is more generic.

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

#217
post #173
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…

Not to mention that python is plenty fast compared to the time it takes to write stuff to the network. Of course heavyweight frameworks like django don't help the equation, but writing fast network code in python isn't exactly hard either.

>python is plenty fast compared to the time it takes to write stuff to the network.

Give us some numbers.

Inside the data centre you have 10G, 40G, 100G ethernet connections. I know for a fact that you will struggle to soak a 10G connection using a single thread so I know you can't do this in Python without multiple processes using SO_REUSEPORT.

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

#218

The general attitude here reminds a bit of the following post from the architect of the Varnish proxy. I think the attitude comes down to the fact that modern kernels and in general the foundations of network programming are pretty strong. We should trust them more. https://varnish-cache.org/docs/5.2/phk/notes.html

I would argue you can say the same about foundations of rdbms systems as well. People build similar elaborate caches around those, for example rails has a “russian doll” cache layer built in, not realizing how much time has gone into developing well tuned caches within the database system itself, which simply needs to be allocated sufficiently large ram.

> not realizing how much time has gone into developing well tuned caches within the database system itself

File systems too. A cron job writing a csv makes a surprisingly simple cache the OS can keep in memory.

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

#219
post #80

Earlier quoted context omitted.

Twitter ran on Rails until 10 million users.

Ah yes, the Fail Whale era.

They should have kept the fail whale instead of offering "Sorry the tweet couldn't be loaded. Please retry" which I get 3/4 of the time on my phone.

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

#220

Earlier quoted context omitted.

I don't really get what the point of this post is. Is it really a dig at python? Python can handle thousands of connections in a single thread no problem with basic enough stuff. Is what the author did supposed to be impressive? Is it supposed to make python look bad? I don't get it. Seems like run of the mill stuff. Python might struggle at the same level of concurrency (was it like 15k?) but you can still do 10k co…

I read it more like: "what if we just use threads instead of avoiding them at all cost and complicate things to get concurrency"

Which I read as "I have no experience whatsoever with modern python, and async is something that catches water".

Async is typically less prone to error and complexity than thread code, and also typically faster/lighter for io (in python). I can't see a reason for this not to be the case in other languages too.

Post reply on HN