8 ms·
I know this is an inevitable comment on any article that calls any software slow, but: "~500 requests/sec" using ten servers? Python may be slow, but I would be
by lclarkmichalek 12y ago
I know this is an inevitable comment on any article that calls any software slow, but: "~500 requests/sec" using ten servers? Python may be slow, but I would be very suprised if it can't do 50req/second.
- falcolas 12y agoThis doesn't pass the smell test for me either. I'm running a Python Django server with a primarily write load on an EC2 small instance, and easily exceeding 50 requests per second, with very low load on the box.
- eps 12y agoIt all depends on what a request is. The req/sec metric alone makes no sense.
- tomwilde 12y agoAs I read it that's one AWS server of unknown size serving ~500rps of an application of unknown complexity. Tripled when using PyPy (whatever that is). Maybe a very small instance serving something fairly complex?
- bkeroack 12y agoYeah, I read it as 500 rps per instance, which is not unreasonable for AWS.
- valarauca1 12y agoHow complex? In one second a modern processor can do ~1 billion operations (ish, some are faster, some are slower, sometimes multiple are done in the same clock tick). Even if its slow, core2 architecture. This means they have the time for about ~200 million instructions per request (Ignoring internal disk I/O, or network I/O). That amount of work is insane! :.:.: I want to say their doing something fundamentally wrong. And it has nothing to do with their language.
- tachyonbeam 12y agoThe i7 can dispatch 4 instructions per cycle. In practice, I find it can realistically execute about 2 per cycle. So at 2GHz, that's closer to 4 billion instructions per second, or ~800M instructions per request as per your calculation. The slowness of their system can probably be blamed on slow database access, or some kind of initialization cost they're paying for every request (i.e.: calling into a binary like in the old CGI days, initializing the Python VM every time).
- valarauca1 12y agoLike I said something fundamentally wrong. With their approach. Un-Indexed databases, databases far away from front end servers (in terms of network topography), or weird VM things with python. Something is bad, and if changing languages solved their problems, they are just sweeping an issue under the rug. It'll hit them in the face later, and harder. Be it developer knowledge, or architectural choices. It'll surface again, they'll (hopefully) be large, and the problem will sting harder too.
- tomwilde 12y agoUnless you're a mathematician or theoretical physicist the gross of your CPU time will be spent waiting for IO. Reading from disk, writing to the network, synchronizing, etc. They're probably just aggregating 2 or 3 APIs, maybe hitting a database and then adding it all together. That description can apply to almost any and all web applications and is inherently IO-bound.
- copx 12y ago>Unless you're a mathematician or theoretical physicist [...] ..or Dwarf Fortress player ;)
- valarauca1 12y agoOooh thank you for reminding me. I recently upgraded to a i7-4790k I've been meaning to jump back into DF now that I should have much better single threaded performance. I honestly haven't played since 2008 on my parents home pentium3.
- loxs 12y agoYep, I could readily point to my Erlang application that can serve thousands of requests per second, doing real work. While simultaneously handling 10k+ websocket connections. All that on a single machine (16G RAM, 8 cores). Does that mean that Erlang is the best? Of course not! It only means that Erlang was specifically designed for this sole use case, which only happens to encompass the whole "web" thingie. It would be an overkill to use Erlang for single-threaded software that requires number crunching speed or for any kind of system scripting. Comparing Erlang to D or Python is stupid. As is (IMHO) using any of the latter for massively parallel servers.