3 ms·

True. Seriously. At least in 2.3. Pre-Rack, I don't imagine that code would have been present.

oldgregg 17y ago
Why the... ???
icey 17y ago
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.
- kscaldef 17y ago
  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.
  - dasil003 17y ago
    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...
    - EvilTrout 17y ago
      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.
      - kscaldef 17y ago
        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.
        EvilTrout 17y ago
        I stand corrected!
    - kscaldef 17y ago
      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.
carbon8 17y ago
It's in 2.3 stable, but it appears to no longer be present in edge (in fact, ActionPack has already gone through a lot of changes): http://is.gd/xP8Y http://is.gd/xP8Y (github link)
- kscaldef 17y ago
  yeah, 3.0 changes a lot. It does appear that it will not exhibit the same problem.
- mtarnovan 17y ago
  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) http://github.com/josh/rack/tree/master http://github.com/josh/rack/tree/master : * NOTE: String bodies break in 1.9, use an Array consisting of a single String instead. p.s. this is definitely worth a 2.3.3 tag and release

Why the... ???

icey 17y ago

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.

kscaldef 17y ago
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.
- dasil003 17y ago
  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...
  - EvilTrout 17y ago
    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.
    - kscaldef 17y ago
      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.
      - EvilTrout 17y ago
        I stand corrected!
  - kscaldef 17y ago
    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.

carbon8 17y ago

It's in 2.3 stable, but it appears to no longer be present in edge (in fact, ActionPack has already gone through a lot of changes): http://is.gd/xP8Y http://is.gd/xP8Y (github link)

kscaldef 17y ago
yeah, 3.0 changes a lot. It does appear that it will not exhibit the same problem.
mtarnovan 17y ago
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) http://github.com/josh/rack/tree/master http://github.com/josh/rack/tree/master : * NOTE: String bodies break in 1.9, use an Array consisting of a single String instead. p.s. this is definitely worth a 2.3.3 tag and release