5 ms·

1. This article was written in 2011 (it's 8 years old). I was confused why they were going with eventlet, but the age of the article explains why. 2. Even for

1. This article was written in 2011 (it's 8 years old). I was confused why they were going with eventlet, but the age of the article explains why. 2. Even for 2011, 1k rps with an average latency of 100ms seems laughably bad. I have to be missing something here.

lewisinc 8y ago
> No one on our team is an Erlang expert Perhaps that has something to do with it
deleted 8y ago
[deleted]
wqwh 8y ago
When you write Python you already know you're throwing the performance out of the window. In fact based on my experience those numbers are pretty good.
- avip 8y ago
  It's trivial to get 1kr/s with the simplest of wsgi flask behind nginx without touching anything. But these "comparisons" are meaningless without asking what "serving the request" is about.
  - y4mi 8y ago
    as much as i love the python ecosystem and django in particular, the parent is definitely correct. Don't ever choose python for performance. Its definitely fast enough for most things, but its just not the tool to leverage if you actually need performance. Its wonderful if you just want to get shit done though, there are just so many good libraries around that you can use to get your project finished without committing several times the effort it takes in other languages
- snotrockets 8y ago
  You can get excellent performance in Python, but at the cost of dev effort – a very deep understanding of the interpreter (and replacing some loops with Cython) would do wonders.
jlouis 8y ago
To be fair, the text doesn't seem to say if we are looking at maximum or average latency. Depending on what is being measured, you will have vastly different opinions on what is good and/or bad latency. Also, note ratio of clients to server is 100:1. So 100ms latency almost has to be the maximally experienced: that single core node cannot spend more than 1ms per request on average, or it will fall behind. The classic problem with these benchmarks are that they fall to what Gil Tene calls coordinated omission. I can park some of the clients for a while and process the other clients far quicker. It improves the req/s and if I'm just coming back to the parked requests within, say, 100ms, everything will look fine. But there is a lot of variance on response times.

lewisinc 8y ago

> No one on our team is an Erlang expert Perhaps that has something to do with it

deleted 8y ago

[deleted]

wqwh 8y ago

When you write Python you already know you're throwing the performance out of the window. In fact based on my experience those numbers are pretty good.

avip 8y ago
It's trivial to get 1kr/s with the simplest of wsgi flask behind nginx without touching anything. But these "comparisons" are meaningless without asking what "serving the request" is about.
- y4mi 8y ago
  as much as i love the python ecosystem and django in particular, the parent is definitely correct. Don't ever choose python for performance. Its definitely fast enough for most things, but its just not the tool to leverage if you actually need performance. Its wonderful if you just want to get shit done though, there are just so many good libraries around that you can use to get your project finished without committing several times the effort it takes in other languages
snotrockets 8y ago
You can get excellent performance in Python, but at the cost of dev effort – a very deep understanding of the interpreter (and replacing some loops with Cython) would do wonders.

jlouis 8y ago

To be fair, the text doesn't seem to say if we are looking at maximum or average latency. Depending on what is being measured, you will have vastly different opinions on what is good and/or bad latency. Also, note ratio of clients to server is 100:1. So 100ms latency almost has to be the maximally experienced: that single core node cannot spend more than 1ms per request on average, or it will fall behind. The classic problem with these benchmarks are that they fall to what Gil Tene calls coordinated omission. I can park some of the clients for a while and process the other clients far quicker. It improves the req/s and if I'm just coming back to the parked requests within, say, 100ms, everything will look fine. But there is a lot of variance on response times.