4 ms·

Another great post! I'm curious what people would suggest as a tech stack that's not python/gunicorn. Something with a GC, decent ORM, that can replace database

Another great post! I'm curious what people would suggest as a tech stack that's not python/gunicorn. Something with a GC, decent ORM, that can replace database-backed services written in Python with similar high level code.

sytringy05 7y ago
You could have a look at Reactive Java, node, golang, even nginx + openresty. Basically anything with an event loop and good non blocking IO support for client requests and you will get loads of traffic through without too much hassle. Of course a lot of this really depends on what your app needs to do over and above handle HTTP requests and what sort of library support you get from language / framework X. Java, for example, has some great reactive libraries, but any JDBC driver blocks (as it has to, enforced by the JDBC spec). There's a couple of non JDBC drivers that support non blocking IO, but they are still evolving. It's a similar story with other languages, there's always something necessary that isn't quite there yet. That said you can still squeeze vast performance out of the blocking IO things with a solid engineering base (Tomcat, IIS if you can stomach windows) you just hit the thread limits earlier and harder than with the non blocking stuff.
enitihas 7y ago
Golang? The go standard library is very good for writing network servers. It is effortless to write a service speaking HTTP with good enough performance. Doing the right thing is also easy. For example, using io.Copy uses splice or sendfile if possible to transfer the data. This makes writing good enough performance servers very easy
tinco 7y ago
Ruby. It's the language with the most intuitive syntax and standard library, the most ergonomic external libraries and an extremely well polished web development ecosystem. Close rivals might be PHP and Node.JS, there's pros and cons to all of them. If something needs to be very performant you pluck it out into a little golang microservice.
- cakoose 7y ago
  The standard Ruby VM (MRI) is about the same speed as the standard Python VM (CPython), aka on the slow end. Twitter famously moved from Ruby to Java/Scala, largely for performance reasons. Node.js is much faster because V8 is much faster, but it's still basically single threaded, so you need to run process-per-CPU, which is what the original blog post (to which this post is a follow-up) was complaining about.
  - tinco 7y ago
    Yeah, the Ruby VM certainly is slow, but that doesn't really matter for most realistic workloads. In Twitter's case it definitely made sense, but do keep in mind that besides switching to Ruby they also switched their entire architecture around to a paradigm that Ruby had no mature ecosystem for at the time. Node.JS is much faster both because it has a fast VM, and because it has concurrency much better dealt with in its standard library than Ruby does (i.e. a proper event loop is built in and its use is idiomatic). That's not what the original blog post was about though, it was about how bad Gunicorn is. I've written Python, but never web apps (since Ruby's superiority there is obvious), but I don't think it's really fair to judge the whole language based on the use of some popular library that's shitty. I think it's symptomatic of Python that the library is shitty, but that's my dislike of Python shining through. The reality is that there are most likely great Python libraries for dealing with concurrent web requests, and she didn't bother to learn them. On Ruby the community would without hesitation recommend you to run Puma or Passenger or even Iodine or Falcon or whatever fancy stuff you have nowadays. These webservers all deal with concurrency, optimizing memory usage, load balancing and managing queues correctly. They don't have silly things like fork'ing before importing libraries, because good software architecture is something that's highly valued in the Ruby community.
    - cakoose 7y ago
      > That's not what the original blog post was about though, it was about how bad Gunicorn is. Yes, the post starts out describing an issue with how Gunicorn listens for connections. Like you said, there are better libraries than Gunicorn so that's not a reason to jump to Ruby. However, the article goes on to talk about other things, like the lack of real multithreading, import-time code execution, and overall efficiency, all of which also apply to Ruby. I'm not saying Python or Ruby are a bad choice. It's just that MapleWalnut was soliciting an alternative that doesn't have the problems described in the original post, so Ruby doesn't qualify.
dnautics 7y ago
So I repeated rachel's experiment with the tech stack that I use (elixir/phoenix). It's got a GC, a database adapter that really does a great job with validations and modeling, and at work I've replaced one django stack with it so far. Not sure if my machine is at all comparable (i5-8265U unplugged laptop CPU @ 1.60GHz) but also the phoenix hello world does a hell of a lot more, like setting session cookies and producing a full front page that renders through two templates. They also took a bit longer to get to in developer time. While you go get a website at :4000 with two commands -- five if you have to install elixir from scratch, it's not really representative of performance: I had to go to prod to disable the live code-reloader and debug/info level logs, disable SSL (releasing to prod defaults to SSL-enabled) and perform a release (elixir these days really wants you to have devops hygeine). 1) I was pretty pleased with the performance. (1900 rps in the base case, 2600 rps in the keepalive case) 2) Unlike Rachel's platform, Elixir is better with concurrency out of the gate (went up to 7800 rps with -c 100), which tells me, the erlang VM is really doing something right. 3) Paying for the cost of having correctly implemented, difficult things like sessions and no XSS would be worth a massive performance hit, IMO. 4) Doing the right thing with Elixir is crazy easy, there's way fewer footguns than python, and code is typically extremely well documented and tested, and inspiring enough to make you want to document and test (though there are fewer libraries).
jacob019 7y ago
In my experience gevent is great, gunicorn not so much. Gevent has a built in HTTP server, it's fantastic. Just take care to avoid CPU bound or blocking code. I use PyMySQL instead of MySQLdb. If speed is a problem then use PyPy. Last summer I spent a month optimizing and updating our public facing django website, getting rid of gunicorn was a big improvement.
anonymoushn 7y ago
Doing great with Openresty over here.

sytringy05 7y ago

You could have a look at Reactive Java, node, golang, even nginx + openresty. Basically anything with an event loop and good non blocking IO support for client requests and you will get loads of traffic through without too much hassle. Of course a lot of this really depends on what your app needs to do over and above handle HTTP requests and what sort of library support you get from language / framework X. Java, for example, has some great reactive libraries, but any JDBC driver blocks (as it has to, enforced by the JDBC spec). There's a couple of non JDBC drivers that support non blocking IO, but they are still evolving. It's a similar story with other languages, there's always something necessary that isn't quite there yet. That said you can still squeeze vast performance out of the blocking IO things with a solid engineering base (Tomcat, IIS if you can stomach windows) you just hit the thread limits earlier and harder than with the non blocking stuff.

enitihas 7y ago

Golang? The go standard library is very good for writing network servers. It is effortless to write a service speaking HTTP with good enough performance. Doing the right thing is also easy. For example, using io.Copy uses splice or sendfile if possible to transfer the data. This makes writing good enough performance servers very easy

tinco 7y ago

Ruby. It's the language with the most intuitive syntax and standard library, the most ergonomic external libraries and an extremely well polished web development ecosystem. Close rivals might be PHP and Node.JS, there's pros and cons to all of them. If something needs to be very performant you pluck it out into a little golang microservice.

cakoose 7y ago
The standard Ruby VM (MRI) is about the same speed as the standard Python VM (CPython), aka on the slow end. Twitter famously moved from Ruby to Java/Scala, largely for performance reasons. Node.js is much faster because V8 is much faster, but it's still basically single threaded, so you need to run process-per-CPU, which is what the original blog post (to which this post is a follow-up) was complaining about.
- tinco 7y ago
  Yeah, the Ruby VM certainly is slow, but that doesn't really matter for most realistic workloads. In Twitter's case it definitely made sense, but do keep in mind that besides switching to Ruby they also switched their entire architecture around to a paradigm that Ruby had no mature ecosystem for at the time. Node.JS is much faster both because it has a fast VM, and because it has concurrency much better dealt with in its standard library than Ruby does (i.e. a proper event loop is built in and its use is idiomatic). That's not what the original blog post was about though, it was about how bad Gunicorn is. I've written Python, but never web apps (since Ruby's superiority there is obvious), but I don't think it's really fair to judge the whole language based on the use of some popular library that's shitty. I think it's symptomatic of Python that the library is shitty, but that's my dislike of Python shining through. The reality is that there are most likely great Python libraries for dealing with concurrent web requests, and she didn't bother to learn them. On Ruby the community would without hesitation recommend you to run Puma or Passenger or even Iodine or Falcon or whatever fancy stuff you have nowadays. These webservers all deal with concurrency, optimizing memory usage, load balancing and managing queues correctly. They don't have silly things like fork'ing before importing libraries, because good software architecture is something that's highly valued in the Ruby community.
  - cakoose 7y ago
    > That's not what the original blog post was about though, it was about how bad Gunicorn is. Yes, the post starts out describing an issue with how Gunicorn listens for connections. Like you said, there are better libraries than Gunicorn so that's not a reason to jump to Ruby. However, the article goes on to talk about other things, like the lack of real multithreading, import-time code execution, and overall efficiency, all of which also apply to Ruby. I'm not saying Python or Ruby are a bad choice. It's just that MapleWalnut was soliciting an alternative that doesn't have the problems described in the original post, so Ruby doesn't qualify.

dnautics 7y ago

So I repeated rachel's experiment with the tech stack that I use (elixir/phoenix). It's got a GC, a database adapter that really does a great job with validations and modeling, and at work I've replaced one django stack with it so far. Not sure if my machine is at all comparable (i5-8265U unplugged laptop CPU @ 1.60GHz) but also the phoenix hello world does a hell of a lot more, like setting session cookies and producing a full front page that renders through two templates. They also took a bit longer to get to in developer time. While you go get a website at :4000 with two commands -- five if you have to install elixir from scratch, it's not really representative of performance: I had to go to prod to disable the live code-reloader and debug/info level logs, disable SSL (releasing to prod defaults to SSL-enabled) and perform a release (elixir these days really wants you to have devops hygeine). 1) I was pretty pleased with the performance. (1900 rps in the base case, 2600 rps in the keepalive case) 2) Unlike Rachel's platform, Elixir is better with concurrency out of the gate (went up to 7800 rps with -c 100), which tells me, the erlang VM is really doing something right. 3) Paying for the cost of having correctly implemented, difficult things like sessions and no XSS would be worth a massive performance hit, IMO. 4) Doing the right thing with Elixir is crazy easy, there's way fewer footguns than python, and code is typically extremely well documented and tested, and inspiring enough to make you want to document and test (though there are fewer libraries).

jacob019 7y ago

In my experience gevent is great, gunicorn not so much. Gevent has a built in HTTP server, it's fantastic. Just take care to avoid CPU bound or blocking code. I use PyMySQL instead of MySQLdb. If speed is a problem then use PyPy. Last summer I spent a month optimizing and updating our public facing django website, getting rid of gunicorn was a big improvement.

anonymoushn 7y ago

Doing great with Openresty over here.