Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

rachelbythebay.com

Post reply on HN
Print view View original

51–60 of 288 posts

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

#51

Post by kragen »

cgh wrote: post #16
simfoo wrote: post #4

Honest question: why go through the hassle of multiplexing waiting in a single thread only to dispatch to a thread per client anyway? Simply using blocking IO for the clients in those threads should be much simpler right?

I think it's basically just the equivalent of select(2)? Once upon a time, all network servers were written this way. They were pretty fast, too.

When was this time? In BSD, which introduced select(2), most network servers ran from inetd. I got a stern talking-to from the computer security folks for running a process in my .cshrc that would repeatedly finger someone at another university, where their fingerd ran from inetd, because I was making their shared VAX run unacceptably slowly. Early versions of httpd included instructions on how to run it from inetd, along with a note that you would probably regret it.

Are you thinking of, like, CICS systems from the 1970s connected to SNA or something? I mean they didn't have select(2) but they did serve many clients in a single process.

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

#52

Post by kragen »

wondringaloud wrote: post #21
sjburt wrote: post #11

Earlier quoted context omitted.

If “real engineering” worked the way you described, we would test planes by filling them full of passengers and flying them around the world. We don’t. We built wind tunnel models, we taxi them around at higher and higher speeds, we put them in machines that wiggle the wings at high loads. The first flight is a little hop and then right back down. Months later there might be a big ceremony with VIPs where the new pla…

She developed a prototype based on a hunch and a whim. Great work, no doubt, but engineering isn't based on intuition and some experience. Real engineering has a goal or specification in mind, and then proves through modeling, analysis, and _finally_ testing that it meets those specs. Whipping something up and then seeing what it's capable of doesn't qualify.

"Whipping something up and then seeing what it's capable of" in simulation or prototype is also known as "modeling and analysis". Prototypes and testing are definitely a valid, even central, part of engineering.

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

#53

Post by luhn »

ivalm wrote: post #22

What WSGI do people recommend for python? I've been using gunicorn but this made me think of alternatives. Quick google search found this benchmark [0], is it really that bjoern is much quicker? It seems all other WSGI are ~ equivalent. [0] - https://www.appdynamics.com/blog/engineering/a-performance-a...

I've been using gunicorn quite happily without the gevent stuff that Rachel ran into issues with. Running 2-3 workers per core is enough for my application to make full use of the CPU. It is a "waste" of memory, but memory is so cheap and plentiful I've never had an issue with it.

bjorn is fast because it has a minimal feature set. No threads, no multiprocessing, no nothing. If it works for you, great, but it's never satisfied my requirements.

I'd avoid uWSGI, it's performance is good but it's so complicated with so many features that I never felt confident using it.

Never used waitress except in development, but people seem to have had success in production.

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

#54

Post by bob1029 »

I think going back to basics would be a really good idea for a lot of people in software. It seems like modern developers are more disconnected than ever from the reality of the hardware situation sitting right next to them. I believe there was a post on the front page today detailing a certain 22ms Hello World execution...

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

#55

Post by stev_stev »

rumanator wrote: post #46
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…

> 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).

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

#56

Post by lazyjones »

The problem with this kind of "benchmark" is that it doesn't measure anything relevant for realistic situations where thousands of connections will behave in arbitrary unexpected ways, like just stalling, and real web applications have absymal worst-case behaviour in case of I/O, cron-jobs running in the background, network hiccups etc.. You don't provision your systems with only best-case situations in mind. But sure, if you want to serve useless random numbers without ever even hitting the disk, a Raspberry PI is able to saturate its network connection.

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

#57

Post by rpedela »

ivalm wrote: post #22

What WSGI do people recommend for python? I've been using gunicorn but this made me think of alternatives. Quick google search found this benchmark [0], is it really that bjoern is much quicker? It seems all other WSGI are ~ equivalent. [0] - https://www.appdynamics.com/blog/engineering/a-performance-a...

Falcon

https://github.com/falconry/falcon

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

#58

Post by yowlingcat »

```

First of all, it does not take "that much machine" to serve a fair number of clients. 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.

```

Another day, another questionable premise for a blog post. No, @rachelbythebay, the question is not "if not that, then what", and the answer is not reinventing the wheel. The question is just "what ___" -- what do you plan on doing, what does your software need to do, what does it need to support? Use the right tool for the right job. If you have a language you're proficient in and with an ecosystem that supports you developing something rapidly, it's borderline malpractice not to start there. When you need to optimize, optimize then. Maybe that means you carve out a subcomponent into a new service, and you choose a language purpose built for speedily doing what you need. Maybe it means a lot of things, but it doesn't mean you throwing out the baby with the bathwater and setting out to recreate the baby, the bathtub, and the bathwater from scratch to answer the question of why your tub is overflowing.

I wish this blog post was about solving real engineering problems instead of writing code to provide mediocre answers to poor questions.

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

#59

Post by rantwasp »

kragen wrote: 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…

if you're going to serve static files, nginx absolutely leaves this in the dust (think 50k rps on a beefy machine)

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

#60

Post by turtlebits »

rumanator wrote: post #46
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…

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

Post reply on HN