Live data from Hacker News

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

rachelbythebay.com

81–90 of 288 posts

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

#81
post #63

Earlier quoted context omitted.

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.

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)

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

#82
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

You ... are not ... Instagram.

Okay. Get over it.

Python is fine. Threads are fine. Go is fine. Clojure is fine. Java is fine. PHP is ... okay I won't go that far. :)

You fix the problem when the cost required to fix the problem is finally less than the opportunity cost of fixing something else.

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

#83
post #76

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)

https://www.phoenixframework.org/blog/the-road-to-2-million-...

yeah. to be fair those are websockets which are sort of the same thing but not really (and performance optimization can be made more easily since the server [mostly] decides when to push stuff)

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

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

IDK but the mod_wsgi, although there seems to be a ton of documentation... It's way harder to install than a virtual environment, python and django. I love doing backend stuff in python and jinja but I fucking hate setting up wsgi on apache. It really makes me love php again.

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

#85
post #79
post #37

Earlier quoted context omitted.

When you hear "Engineer", you often think of calculus, statistics, formal testing, requirements gathering, documentation, repeatable results, etc... along with a fundamental understanding of the problem space and possible solutions. I think this is akin to NASA working on the Apollo program vs. someone in their garage attempting to build a go-cart for the first time. When you just slap things together and see if they…

>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 engineering. It's experimentation, not testing.

When the outcome is unknown and unreliably unpredictable, it's research (tinkering). When it's predictable and has a known, repeatable outcome, it's engineering.

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

#86

Earlier quoted context omitted.

I’ll bite, is it slack?

In all honesty, there's a whole slew of platforms it could be: - Slack - Keybase - Mattermost - Discord - Microsoft Teams - Facebook Messenger (incl. Work) All of these fine folks apparently use Electron or a similar technology...

Or it could be Rambox with all of those!

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

#87
post #63

Earlier quoted context omitted.

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.

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.

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

#88
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'm using Waitress in production: https://docs.pylonsproject.org/projects/waitress/en/stable/ It's main thing is that it's really simple, worth a look if you're using Django.

going to look at this in depth tomorrow. Thanks

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

#89
The typical response to these types of posts is "oh your /toy/ server doesn't account for x, y, z in my use case, like ddos, network issues, etc. But how many people actually handle those cases in your production application? I can say for the majority of the applications I've written at large companies handling significant traffic API compatibility was far higher on the priority list than the cases that people often bring up.

IMO she's right, I wish we didn't mess wrap around gunicorn and gevent for some of our services. Certainly would've made my life easier and the services faster.

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

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

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

Post reply on HN