I didn't know you could turn off caching in chrome. I'll have to take a
better look into their dev tools. Once you figure this out, it could make a
nice blog post on how to use front end + backend analytics to debug and
speed up performance problems.


On Wed, Feb 19, 2014 at 12:02 PM, Rodrigo Rosenfeld Rosas <
[email protected]> wrote:

>  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]> 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].
>> 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.
>
>
>  --
> 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.

Reply via email to