RE: Resource timing buffer

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