4 ms·

I submitted this because I thought it might make for some good discussion, but: > This post is my attempt to be fair, objective, and, by consequence, unrelenti

I submitted this because I thought it might make for some good discussion, but: > This post is my attempt to be fair, objective, and, by consequence, unrelentingly negative about Rails :) To me it seems arrogant to assume that you are being fair and objective when you only point out the negative attributes of something. I'd be more inclined to assume that there are positives I'm overlooking, that might even outweigh the negatives. Especially for something as beloved by developers as Rails. What evidence is there that running a process per core has a significant negative effect on throughput and/or latency in practice? Benchmarks? Data from developers who tried both approaches while holding all else constant? (The latter is probably quite difficult in practice.) Also, JRuby supports real threads without a global interpreter lock. I think I agree with this post about the benefits of static typing, though.

kevingadd 13y ago
Objectivity is a separate thing from the topic of the post. He came into it wanting to write an explanation of why he thinks you should never use Rails, and attempted to be objective about it by including data and describing some caveats to his argument (i.e. scenarios where you might be able to get away with it). A post that says 'why you should or shouldn't use rails' is a different post and no more or less implicitly objective. Objectivity does not mean 'covering two sides of an argument'; sometimes one side is less or more supported than the other and sometimes you simply don't have the knowledge to cover both sides fairly.
hatsix 13y ago
... also, the evidence for the performance is the benchmark image in the sidebar.
el_bhs 13y ago
(I wrote TFA -- didn't expect it up on HN!) I agree that the post would be more compelling if I wrote a benchmark to demonstrate how much faster an in-memory cache is than an off-process or off-machine cache. From first principles, though, I believe it should be obvious (yes?) that the ~300 nanoseconds it takes to grab a read lock and read from main memory is going to beat the ~1000000 nanoseconds it takes to get a response back from a remote cache over the network. Inasmuch as an application blocks on such cache reads, these sorts of things add up to troublesome latency numbers (and Rails – or at least dallistore – does indeed block on reads like these). JRuby was off the table for the place I used rails due to reliance on some C extensions. And I'm sorry if the argument seemed arrogant: I was being tongue-in-cheek about the "unrelenting negativity" part. My point about objectivity was that I tried not to rely on my opinions as much as demonstrable statements. That said, I didn't take the time to actually demonstrate most of those, and for that, shame on me.
- mwcampbell 13y ago
  How about the performance difference between an in-process cache and a memcached instance on localhost? Surely anyone who knows what they're doing will run the cache on the same machine as the web server. (I guess that makes a good argument for not using a PaaS that gives you too little control over locality.)
  - el_bhs 13y ago
    This is a lazy answer, but it needs to be said: it depends on the context and the number of roundtrips to the cache. If we're talking about a vanilla object cache, I think that it probably only costs 50% or so to make the extra copies and system calls. However, an in-memory "cache" can be something more than just a key-value store. E.g., for the thing I'm building right now, there are some more structurally complex graph structures that need to be traversed with every request to the "cache", and of course making a localhost RPC call for each entry/exit to the cache is really problematic. Though I admit that most caching is unsophisticated stuff, and in those cases it's just a ~2x difference.
- bhauer 13y ago
  Incidentally, we will be adding a cached test in a later round [1] and leaving the implementation particulars in large part to the best-practices of the platform or framework in question. So on Rails, use of memcached is anticipated. On a JVM platform, by comparison, use of a [distributed] in-process cache is anticipated. Preliminary results suggest an even wider spread of results than seen in the existing single-query test. [1] https://github.com/TechEmpower/FrameworkBenchmarks/issues/374 https://github.com/TechEmpower/FrameworkBenchmarks/issues/37...

kevingadd 13y ago

Objectivity is a separate thing from the topic of the post. He came into it wanting to write an explanation of why he thinks you should never use Rails, and attempted to be objective about it by including data and describing some caveats to his argument (i.e. scenarios where you might be able to get away with it). A post that says 'why you should or shouldn't use rails' is a different post and no more or less implicitly objective. Objectivity does not mean 'covering two sides of an argument'; sometimes one side is less or more supported than the other and sometimes you simply don't have the knowledge to cover both sides fairly.

hatsix 13y ago

... also, the evidence for the performance is the benchmark image in the sidebar.

el_bhs 13y ago

(I wrote TFA -- didn't expect it up on HN!) I agree that the post would be more compelling if I wrote a benchmark to demonstrate how much faster an in-memory cache is than an off-process or off-machine cache. From first principles, though, I believe it should be obvious (yes?) that the ~300 nanoseconds it takes to grab a read lock and read from main memory is going to beat the ~1000000 nanoseconds it takes to get a response back from a remote cache over the network. Inasmuch as an application blocks on such cache reads, these sorts of things add up to troublesome latency numbers (and Rails – or at least dallistore – does indeed block on reads like these). JRuby was off the table for the place I used rails due to reliance on some C extensions. And I'm sorry if the argument seemed arrogant: I was being tongue-in-cheek about the "unrelenting negativity" part. My point about objectivity was that I tried not to rely on my opinions as much as demonstrable statements. That said, I didn't take the time to actually demonstrate most of those, and for that, shame on me.

mwcampbell 13y ago
How about the performance difference between an in-process cache and a memcached instance on localhost? Surely anyone who knows what they're doing will run the cache on the same machine as the web server. (I guess that makes a good argument for not using a PaaS that gives you too little control over locality.)
- el_bhs 13y ago
  This is a lazy answer, but it needs to be said: it depends on the context and the number of roundtrips to the cache. If we're talking about a vanilla object cache, I think that it probably only costs 50% or so to make the extra copies and system calls. However, an in-memory "cache" can be something more than just a key-value store. E.g., for the thing I'm building right now, there are some more structurally complex graph structures that need to be traversed with every request to the "cache", and of course making a localhost RPC call for each entry/exit to the cache is really problematic. Though I admit that most caching is unsophisticated stuff, and in those cases it's just a ~2x difference.
bhauer 13y ago
Incidentally, we will be adding a cached test in a later round [1] and leaving the implementation particulars in large part to the best-practices of the platform or framework in question. So on Rails, use of memcached is anticipated. On a JVM platform, by comparison, use of a [distributed] in-process cache is anticipated. Preliminary results suggest an even wider spread of results than seen in the existing single-query test. [1] https://github.com/TechEmpower/FrameworkBenchmarks/issues/374 https://github.com/TechEmpower/FrameworkBenchmarks/issues/37...