Re: Resource timing buffer

I like Arvind's simpler model as well. By triggering the 
onresourcetimingbufferfull callback at N instead of N+1, it gives the 
developer the opportunity to either call clearResourceTimings() or grow 
the buffer incrementally via setResourceTimingBufferSize() , 
theoretically, with little chance for 'lost events'.

Maybe an example best practice could be provided so developers see they 
shouldn't have to setResourceTimingBufferSize(9999)?

For example:

    <script>

    var bufferSize = 150;
    setResourceTimingBufferSize(bufferSize);

    function bufferFullCallback() {
         var latestTimings = performance.getEntriesByType('resource');

         // OPTION 1: clear ResourceTimings right away so new events
    will be captured
         // performance.clearResourceTimings();

         // OPTION 2: grow the buffer incrementally:
         // bufferSize += 10;
         // setResourceTimingBufferSize(bufferSize);

         // you can now analyze, store or XHR 'latestTimings' and new
    ResourceTimings will continue to be captured
    };

    performance.onresourcetimingbufferfull=bufferFullCallback;
    <script>


- Nic
http://nicj.net/
@NicJ

On 5/1/2013 11:21 AM, Jatinder Mann wrote:
>
> I think the initial thought process here was that we wouldn't throw 
> out any data for developers that were interested in capturing all the 
> data. E.g., those that implemented a onresourcetimingbufferfull 
> attribute handler.
>
> However, I can't recall seeing such a complicated buffer model in 
> other specs. From some of our initial investigation, I recall that 
> most websites use less than 150 resources, which is the recommended 
> default buffer size. Additionally, developers can always just increase 
> the size of their buffer size early on in the page lifetime if they 
> know that they have more than 150 resources.
>
> I rather we keep the simpler model suggested in this thread.
>
> FYI - IE10 actually implements a larger buffer size to be on the safe 
> side.
>
> Thanks,
>
> Jatinder
>
> *From:*Arvind Jain [mailto:arvind@google.com]
> *Sent:* Tuesday, April 30, 2013 3:04 PM
> *To:* James Simonsen
> *Cc:* Nic Jansma; public-web-perf
> *Subject:* Re: Resource timing buffer
>
> I've updated the draft to reflect Pan's comments (call the 
> onresourcetimingbufferfull callback on Nth instead of N+1th entry), 
> and drop the logic for storing entries beyond N while executing the 
> callback (given nobody seems to have implemented that logic).
>
> Please take a look at section 4.4 and 5.3.20 and let us know if there 
> are any concerns. We can discuss this in tomorrow's telecon.
>
> Arvind
>
> On Tue, Apr 30, 2013 at 10:21 AM, James Simonsen <simonjam@google.com 
> <mailto:simonjam@google.com>> wrote:
>
>     I wonder if we have to say this at all. The web is single
>     threaded. I believe most of the specs assume that. It's up to the
>     browsers to maintain that illusion and this could just be part of it.
>
>     James
>
>     On Mon, Apr 29, 2013 at 6:38 PM, Nic Jansma <nic@nicj.net
>     <mailto:nic@nicj.net>> wrote:
>
>         While in onresourcetimingbufferfull, getEntries() was intended
>         to be "stable", i.e. it should have "buffer size" (N) number
>         of entries.  New RT entries occuring during the callback would
>         go into a queue. Then, per option #1 in
>         onresourcetimingbufferfull, if clearResourceTimings() is
>         called, the first N entries are removed and N+1 queued entries
>         onward take their place.
>
>         Without the onresourcetimingbufferfull text, I'd be worried
>         that the developer could lose RT events.  If they're
>         interested enough to listen to onresourcetimingbufferfull,
>         they probably want every single RT event, and the only way to
>         work around the possibility of lost events during the callback
>         is to just set a huge buffer instead and call it a day.
>
>         But it does complicate things and the description is kind of
>         hard to follow. I can't think of any other web APIs that
>         require this level of buffer management to follow the lead from?
>
>         - Nic
>
>         http://nicj.net/
>
>         @nicj
>
>         On 4/29/2013 9:18 PM, James Simonsen wrote:
>
>             That implies that the buffer can change while
>             the onresourcetimingbufferfull callback is running. Is
>             that expected? That'd mean it's not safe to
>             clearResourceTimings() after getEntries(), because a new
>             entry may have appeared in the meantime.
>
>             In Blink, this would only be possible if a synchronous
>             request took place during the callback. I don't think
>             that's something we should go out of our way to support.
>
>             James
>
>             On Mon, Apr 29, 2013 at 6:10 PM, Nic Jansma <nic@nicj.net
>             <mailto:nic@nicj.net>> wrote:
>
>                 I believe the idea was to give the developer the
>                 opportunity to smartly manager their RT buffer instead
>                 of just setting it at 10,000 (and consume resources)
>                 so they didn't have to worry about it.
>
>                 For example, a developer could leave the default 150
>                 buffer size and:
>                 1) Listen to onresourcetimingbufferfull
>                 2) When onresourcetimingbufferfull is triggered:
>                 2a) getEntriesByType(...) and
>                 analyze/process/submit/store these 100 resources if
>                 they wanted
>                 2b) clearResourceTimings()
>                 3) In the meantime, the browser has been caching any
>                 new entries and takes the action defined in
>                 onresourcetimingbufferfull
>                 (http://www.w3.org/TR/resource-timing/#dom-performance-onresourcetimingbufferfull)
>                 after the callback has completed.
>                 4) The developer can now analyze any new events that
>                 came in during step #2 or wait for the next
>                 onresourcetimingbufferfull
>
>                 Otherwise, if any new RT events come in after #1, and
>                 the browser stops recording them, the developer has no
>                 way of knowing they occurred and cannot retrieve them.
>
>                 - Nic
>
>                 http://nicj.net/
>
>                 @nicj
>
>                 On 4/29/2013 7:32 PM, Arvind Jain wrote:
>
>                     http://www.w3c-test.org/webperf/specs/ResourceTiming/
>
>                     Re. this comment:
>
>                     onresourcetimingbufferfull attribute
>                     ....*While executing the
>                     onresourcetimingbufferfull callback,
>                     PerformanceResourceTiming will continue to be
>                     collected beyond the maximum limit of the
>                     resources allowed*....
>
>                     I tried to look up why we added it and couldn't
>                     find anything. Currently this logic is not
>                     implemented by IE and Chrome.
>
>                     Should we remove this? i.e. once the limit is
>                     reached, don't store new resource timing objects
>                     irrespective of whether you are executing this
>                     callback or not.
>
>                     Arvind
>