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.
Old box, dumb code, few thousand connections, no big deal
101–110 of 288 posts
Re: Old box, dumb code, few thousand connections, no big deal
#102Would love to see the code.
me too.
said it has no real purpose yet. that's key. no doubt she knows what she is writing about and also picked a favorable language. but the gunicorn folks have also been doing this server thing forever now. they probably have their share of stories.
hope some code gets released soon.
Re: Old box, dumb code, few thousand connections, no big deal
#103Whether 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…
> 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…
It does not take that much time to get up to speed on another tech stack, but it does take some time, and servers are really cheap. Even if the learning curve is close to none, it's just cheaper to rent a dozen machines than have an engineering team spend a day or two looking into a new ecosystem.
Re: Old box, dumb code, few thousand connections, no big deal
#104Rachel 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…
> single-threaded nonvectorized C wastes on the order of 97% of your computer's computational power Can you elaborate on what this means exactly? For example, is there some reasonable C code that runs 33 times slower than some other ideal code? In what sense are we wasting 97% of our computer's computational power?
I imagine if you could make the most out of vector instruction set in your code (where they can operate on a vector of data at once instead of one by one), you'll get a huge performance boost for "free". GP seem to be working on a vm that let you do that (a lot of it was flying over my head though, need some coffee).
Re: Old box, dumb code, few thousand connections, no big deal
#105Earlier quoted context omitted.
went back and looked at it. a webserver written in asm for the lols is okay but my point was that you probably want a proven, battle ready web server (along the lines of nginx or apache) if running something in production. So, 50k rps on a vanilla well used/well maintened server > 50k rps on an experiment (and don't get this wrong, it's pretty impressive for what it is)
Yeah, I definitely wouldn't advise anyone to run httpdito in production. It's so lacking in observability that it doesn't even log hits, it doesn't do timeouts, and its MIME types are configured by writing in assembly language. But it shows that some surprising things are possible. And it can be handy to serve up some static pages from your laptop to your phone or whatever.
https://gist.github.com/willurd/5720255 Each of these commands will run an ad hoc http static server in your current (or specified) directory, available at http://localhost:8000.
Re: Old box, dumb code, few thousand connections, no big deal
#106Earlier quoted context omitted.
I think the previous poster was just exaggerating... "All" network servers is a pretty broad category. They were never all written using select.
They were never mostly written using select, either.
you are correct. I'm not the original poster though.
Re: Old box, dumb code, few thousand connections, no big deal
#107Earlier quoted context omitted.
Yes, using epoll with nonblocking I/O is better than blocking I/O on each worker thread. But that basically means that you are doing asynchronous programming--i.e., the exact same thing that the wonky Python/Gunicorn stack you described is doing! You're just doing it with better attention to important details. Here, to me, is the key item: The "listener" thread owns all of the file descriptors (listeners and clients…
Better attention to important details is what makes or breaks a library.
Exhibit A: Dropbox (attention to detail and executing it)
Re: Old box, dumb code, few thousand connections, no big deal
#108Whether 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 liability rather than an asset.
I always say this opinion when it comes to Python discussion in HN and I always get downvoted but hey, "all it takes for evil to triumph...".
Re: Old box, dumb code, few thousand connections, no big deal
#109Earlier 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…
This is where my head always goes as someone who does mostly Asp.Net Core. Why is it always between something like C++ or something like Python? Nowadays with middleware and endpoint routing, asp.net core can be almost as simple as flask (even if that’s not idiomatic or what the docs show you).
Or Azure Functions if you want to go the serverless route. Coupled with Visual Studio, you can build high quality, large scale apps at about the same effort of blinking a LED on Arduino.
Re: Old box, dumb code, few thousand connections, no big deal
#110Earlier 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…
I disagree. I tried to learn F# a few months ago and the experience was horrible. I followed the tutorial using the aspnet CLI tool and got nothing but errors. I Google’d for a while until I gave up.
Can you link to the tutorial you followed?