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

61–70 of 288 posts

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

#61

Post by hedora »

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…

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

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

#62

Post by bdavis__ »

rantwasp wrote: post #59
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)

of course it does !!

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

#63

Post by kragen »

rantwasp wrote: post #59
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)

I would expect so, but did you mean 500k or something? "50k rps on a beefy machine" sounds like about the same as, or maybe even a bit slower than, 20k–30k on this 2011 laptop, which was how fast httpdito was last time I measured it.

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

#64

Post by anonymoushn »

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…

It seems like doubling down is the standard thing to do. Here's a video about how Instagram bugs engineers to do fewer string manipulations in Python instead of using a faster language https://youtu.be/hnpzNAPiC0E

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

#67

Post by icedchai »

kragen wrote: post #51
cgh wrote: post #16

Earlier quoted context omitted.

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,…

Long running network servers, such as most IRC servers, were written using select. Example: https://en.wikipedia.org/wiki/Comparison_of_Internet_Relay_C...

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

#68

Post by kragen »

icedchai wrote: post #67
kragen wrote: post #51

Earlier quoted context omitted.

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,…

Long running network servers, such as most IRC servers, were written using select. Example: https://en.wikipedia.org/wiki/Comparison_of_Internet_Relay_C...

IRC servers were indeed written using select(2), because interaction between the clients is the whole point of IRC; that gets a great deal more difficult if you spawn off a separate process for each client! I think ICB/FNet predates IRC slightly and was also written using select(2). But IRC wasn't written until 1988, at which point select(2) and inetd were already about ten years old, and things like (most) FTP servers continued to run one process per concurrent client throughout the 1990s. (Walnut Creek CDROM wrote their own high-performance event-driven FTP server, IIRC.) Typically on the machine where you were running the IRC server you would also be running about a dozen or two other servers from inetd, all written with the one-process-per-client model.

If there was a time when all network servers were written using select(2) or similar event-driven APIs, it wasn't 1988 or later.

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

#69

Post by knolax »

thenewwazoo wrote: post #7

But this isn’t engineering. This is the IT equivalent of building a bridge and driving successively larger trucks over it. In real engineering fields, you can do predictive analyses based on prior empiricism. There’s none of that in our fields until you’re talking about very small systems where, for example, the stack consumption can be determined in advance and the scheduler can give you guarantees about worst-case…

> building a bridge and driving successively larger trucks over it.

And that's not engineering?

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

#70

Post by Falell »

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 use uwsgi at work, we've found a lot of bugs in the more interesting features of the uwsgi module, and had to fix some signal and memory leak issues (I think we're still trying to get them upstreamed). That said, it's reasonably fast and the WSGI interface in general is pretty pleasant to work with.
Post reply on HN