Re: Need advice about how chunked streaming technologies work with cache settings

On 05/13/2012 05:20 PM, AlanO wrote:
> I'm working with the HDS streaming technologies, within the Adobe
> Flash world, and I'm trying to compile a set if 'FAQs' about each main
> browser available to consumers and how it will react to the 'chunks'
> being delivered via the HTTP stack.

I can answer some of your questions, though I'm not sure how they 
specifically relate to HDS streaming.

> 1/ What is the default setting in Firefox for the Cache? Is it RAM
> then Disk. Is this flow described anywhere?

We currently only use the RAM cache for for requests that can't be 
stored on disk--no-store and certain SSL requests.  So the flow as data 
comes in is that data is delivered immediately to the program logic that 
requested it, plus asynchronously scheduled to be written to the disk 
cache.

For media requests (such as HDS), our media processing layer also has 
its own, RAM-backed cache.    I'm not sure what state the data is in 
(decoded in any form yet) while it's in the media cache.   But our media 
cache is probably not getting used for Flash, so it's probably not 
relevant for you.  Our DASH implementation will use it, though.

Is there a specific issue related to caching and HDS that you're 
concerned about?

> 2/ How is garbage collection instigated - the latest Firefox has an
> option suggesting that, by default, there is an automatic garbage
> collection which must use some rules... perhaps about disk space? For
> example: in Google Chrome, the default cache can take up huge amounts
> of disk space growing without some sort of size limit it seems, plus
> you can only change the cache settings on the CLI of Chrome (no
> 'consumer' level configuration in the 'preferences' dialogs).

I assume by "garbage collection" you're referring to evicting items from 
the HTTP cache (we usually reserve "garbage collection" for other things 
not related to the cache, like collecting reference counted objects in 
memory).   Both Chrome and Firefox use a LRU (least-recently-used) 
algorithm to evict items from the disk cache, and we also both use an 
algorithm that grabs up to a certain % of disk drive space (the % drops 
as the disk size increases), up to 1 GB max.    In Firefox you can 
easily provide a user-defined cache size instead--the UI for it is in 
Preferences | Advanced | Network | Override automatic cache 
management.   Or you can set it in about:config  by setting 
'browser.cache.disk.smart_size.enabled' to false, and  
'browser.cache.disk.capacity' to the size you want.


> 3/ What are the methods employed when multiple chunks are requested -
> as with loading a web page, there is some 'pipeline' going on in the
> network stack. Perhaps limiting the total number of working threads
> for 'same domain' requests - this could impact on HDS chunks. Consider
> where more than one HDS stream is present in a users browser (e.g.
> multiple tabs/windows with an HDS stream) - if chunks are served from
> the same FQDN, would there be a 'fight' due to slots within the worker
> threads in the network stack?
>
> Although I mention HDS here, this would likely go for any other
> chunked streaming methods (MPEG-DASH, HLS) which may have a client
> implemented inside a browser host.
We do have a bunch of limits for the maximum number of TCP connections 
we allow to a server (or a proxy server, if that's being used).  Search 
for "connections" in about:config and you'll see them.   Generally the 
limit is 6 per FQDN (for persistent connections, which are the most 
common) or 15 for non-keep-alive connections.   When using a proxy we're 
limited to 8 connections total (across all domains, IIRC), so that's a 
more constrained case.  These limits are also lower on mobile 
Firefox--don't recall them off the top of my head, can let you know if 
you need them.

We do have a queuing system for when there are more HTTP requests for a 
domain pending than we have free connections (I'm assuming that's what 
you mean by 'pipeline' here?  It doesn't sound like HTTP pipelining per 
se as in RFC 2616, which is a particular way of handling queued 
connections, in some sense, but it sounds like you're talking about the 
general case of "more requests than connections").  So if you have more 
HDS streams (and/or other requests to the same domain) pending than the 
above connection limits, some of them will have to wait for the others 
to complete before being satisfied.  It's definitely not a good idea to 
request 8 media chunks in the reverse order that they'll be needed, for 
instance.

Does that answer any of your questions?  I think it might help to have 
more of an idea of what problems/issues you're anticipating, or specific 
info you need for your guide.

cheers,

Jason
Mozilla