Live data from Hacker News

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

rachelbythebay.com

161–170 of 288 posts

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

#161

Earlier quoted context omitted.

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.

Are we using the same Azure Functions? I spend more time messing with functions.json and determining binding types and waiting five minutes for error messages to come in than I ever did when I simply provisioned an app service and deployed code.

[deleted]

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

#162

> 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. I actually want to know: then what? As a web developer who usually reaches for Django or Flask with Gunicorn because I just don't know any better, is there a better stack that doesn't face these pr…

If you're shy about managing your own memory and want to stay in a higher level language you could use the Quarkus framework or Micronaut which are Java on the JVM. Kotlin is a super-set of the java language and also adds a lot more syntactic sugar. I don't have experience w/ kotlin, YMMV. The introduction of Lambdas and the choice of modern post-EE java frameworks really takes a lot of the grind out of programming in Java. With the upcoming data classes it's going to get even better.

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

#163
post #39

Unfortunately this approach precludes GIL languages like Python. If you're able to use a language/runtime that is amenable to multithreading, then using a thread per connection works fine for most use cases (and it's probably easier than using whatever async/await interface your language has).

True that the GIL prevents the specific expressed pattern you're talking about, but many have been able to do multiple threads and processes with Python itself and also things like gunicorn or uwsgi.

Yes, but I was responding to the article which was describing alternative patterns besides wsgi.

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

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

If you get stuck in read(), you can't do neat things like waking up when it's time to kick a client for being idle, doing other housekeeping, or cleanly shutting down the whole thing in a timely fashion. When I ^C the server, it sends the same wake condvar-poke but it twiddles the flags so the worker shuts down instead.

Good point. Would still be possible with the threads being blocked in a read() but that would require signals and more logic in the threads, so a central multiplexing and coordinating thread seems like a cleaner solution.

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

#165
post #61

Earlier quoted context omitted.

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

> reimplement it in bash > more debuggable / readable More debuggable / readable for you, perhaps.

Hey, for me too. But then again I used to write bash frameworks for fun so there's that.

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

#167

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…

Learning curve close to none? I like that many times there's "the way" of doing things, but when I have to do something slightly outside the recommended way, I feel that the effort required outweights all the benefits.

Isn't that true for all frameworks?

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

#168
post #145

Earlier quoted context omitted.

> 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. I think the point of this post is that most new programmers do not know things can be faster than their monstrous JS blob. The solution to slow requests is more servers instead of fixing the code.

In what way is this helpful to newcomers at all? It uses a ton of heavy jargon and no example code.

It’s not aimed at introductory programmers. It’s aimed at more experienced programmers to suggest to them that they can show new programmers what’s possible.

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

#169

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…

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.

> I tried to learn F# a few months ago and the experience was horrible.

Switching to a programmig language based on an entirely different programming paradigm is not comparable to switching to a language based on the exact same programming paradigm to develop the exact same application using the exact same design patterns.

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

#170
post #80
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…

Twitter ran on Rails until 10 million users.

But how many instances did they have running that app, and at what cost? Did they have to build a ridiculous amount of caching in? And wasn't that the time period where they were incredibly unreliable to the point that their "fail whale" server error page became a running gag?
Post reply on HN