On 19-02-2014 13:44, richard schneeman wrote:
This functionality does not come from Rails, but rather Rack::Runtime
(http://guides.rubyonrails.org/configuring.html#configuring-middleware) you
can see the middleware here:
https://github.com/rack/rack/blob/master/lib/rack/runtime.rb. It looks
pretty simple, i'm not sure if it is streaming aware.
For different latencies regarding assets, i'm guessing that chrome is
perhaps doing some caching? How much latency do you get when you hit
that CSS from a new incognito window?
I don't need an incognito window to force skipping any caching, I just
check "Disable cache (while DevTools is open)". I did that and I can see
from the Network pane that the response status was 200, and it took 16ms
of latency + 30ms of "Receiving" time for a JS asset.
What I mean is that most probably the web server (Puma, Webrick) is not
the cause for such a big latency... So maybe there's something more
happening that is not registered by that middleware and I'd like to know
if there's anyway I could understand what else it could be and if I'm
able to optimize it...
Just in case you're curious, I tested it in an incognito window and the
result is the same as disabling cache.
From my understanding rendering as a stream won't make the whole page
load faster, it will just send elements to the browser as soon as they
are ready so the HTTP request would still take just as long, but the
end user sees content sooner and the browser has more time to parse
and fetch CSS/JS/etc. Perhaps chrome is measuring the request time?
I understand that and that's exactly my intention. I want Chrome to
download the assets while the page is loading but I see that it won't
download them until the page finishes loading, which makes sense since I
get about 3ms of "Receiving" time. What I mean is that rendering with
"stream: true" is not helping at all and it makes no difference if I use
normal rendering (except for this bug I reported yesterday:
https://github.com/rails/rails/issues/14093)
Chrome reports me all timings separately: "Blocking", "Sending",
"Waiting" and "Receiving". The waiting part is taking 99% of the total
time. Do you get different results?
I have even included this in one of my partials:
<% sleep 1 -%>
Guess what: "Waiting: 1.1s"
So, I guess the problem is that streaming doesn't seem to be working
actually.
Now that I figured this out, I'll try to reproduce in a separate
application and if I can, I'll report another bug for template streaming
rendering.
Thank you for helping, Richard.
Cheers,
Rodrigo.
On Wed, Feb 19, 2014 at 8:42 AM, Rodrigo Rosenfeld Rosas
<[email protected] <mailto:[email protected]>> wrote:
As far as I understand, Rails uses a middleware by default that
will send the total time spent on a request in the Rails side in
the X-Runtime HTTP header.
But it doesn't seem to be reliable in the sense that when I
perform a request against http://localhost:3000/ (development
environment, tested with both Puma and Webrick), I get 10ms of
latency when serving some CSS assets but 109ms of latency for the
index page. When I look at the header for the same request, I get
"X-Runtime: 0.034849".
Here's how it reports the timing in the server logs:
Completed 200 OK in 22ms (Views: 1.4ms | Sequel: 13.2ms)
Rendered search/_fields_finder.html.erb (0.0ms)
Rendered search/_left_pane.html.erb (0.7ms)
Rendered search/_index.html.erb (8.9ms)
Rendered transactions/_list.html.erb (0.0ms)
Rendered search/_saved_searches_dialogs.html.erb (0.2ms)
Rendered search/_saved.html.erb (0.5ms)
Rendered main/_change_log.html.erb (0.1ms)
Rendered main/_glossary.html.erb (0.0ms)
Rendered themes/default/_footer.html.erb (0.1ms)
Rendered main/index.html.erb within layouts/main (70.5ms)
This happens because I'm using "render stream: true" in that
action, but I'd expect the latency to be reduced when looking at
the Chrome reported timing, but it doesn't matter if I render with
"stream: true" or not, the latency reported by Chrome is always
about 100ms.
Am I missing something?
Thanks in advance,
Rodrigo.
--
You received this message because you are subscribed to the Google
Groups "Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected]
<mailto:rubyonrails-core%[email protected]>.
To post to this group, send email to
[email protected]
<mailto:[email protected]>.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google
Groups "Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Ruby on
Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.
