String.each is the same as String.each_line in ruby 1.8. This code rewrite seems to be the reason that code breaks on ruby 1.9 if body is a string (this is guarded against in the body setter). (ruby 1.9 removes String.each)
Is there a lot of per-line processing in Rails? Or is this something caused by Rack?
I know next to nothing about Rails, so I'm sorry if these are questions with obvious answers. I just think the decision to process body responses on a per-line basis seems odd.
It's definitely odd. I'm inclined to attribute it to carelessness, and just not really thinking about the implications of precisely how they chose to implement the Rack specification.
What's frustrating is that apparently there wasn't any performance testing of the 2.3 release that ought to have found this problem. It's been in the code base for about a year at this point.
How often is ActionResponse.body a String? It's not really clear to me without digging deeper, but I could see this easily being an edge case related to certain caching and rendering methods. In any case, suggesting that any performance testing of Rails would have magically found this problem is unfair. Many many many Rails app instances are serving orders of magnitude more than 10reqs/sec, so clearly this is not a universal problem.
My guess as to the reasoning here is so that large files can be served without blocking while the whole thing is written to the socket. Granted, that's just my gut instinct looking at that code, maybe it is just careless...
I checked that, and I couldn't find any case where the body _wasn't_ a String.
It's true, that the problem only becomes really glaring when the pages being served are quite large (this example was 1300 lines of HTML), but I still assert that good performance regression testing ought to have popped this up. With 100 lines of output, which is pretty reasonable, you'd still be looking at an extra 10ms on each request.
I've been running Rails 2.3 in production for a while with great performance.
In the article the author mentions it has to do with serving static files, which is something that nobody should be using Rails to do anyway. I'm not surprised nobody found it until now.
No, we only incidentally found it while working on a piece of our app that serves static files. The issue looks universal to me, although with dynamic content or smaller output, the relative hit would be less noticable.
