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.
Old box, dumb code, few thousand connections, no big deal
161–170 of 288 posts
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…
Re: Old box, dumb code, few thousand connections, no big deal
#163Unfortunately 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.
Re: Old box, dumb code, few thousand connections, no big deal
#164Honest 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.
Re: Old box, dumb code, few thousand connections, no big deal
#165Earlier 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.
Re: Old box, dumb code, few thousand connections, no big deal
#166Try it today with NGINX.
Re: Old box, dumb code, few thousand connections, no big deal
#167Earlier 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.
Re: Old box, dumb code, few thousand connections, no big deal
#168Earlier 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.
Re: Old box, dumb code, few thousand connections, no big deal
#169Earlier 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.
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
#170Whether 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.