Hi Dylan,

Thanks for this information; this is exactly the sort of thing I was hoping would come out of the wood work.

I will need to take a good look and see if it is something that will impact us.

Really do appreciate the heads up.

Regards

Paul

---

From: Dylan Hall [mailto:dylan@citylink.co.nz]
Sent: Wednesday, 12 August 2009 11:38 a.m.
To: Paul Tinson
Cc: nznog
Subject: Re: [nznog] Telecom International HTTP Caching

We (The Citylink streaming media platform) hit an interesting problem with the TelstraClear caches a while back that may crop up with the Telecom caches.

We have a number of customers serving content (flash video via http) that require a sustained throughput of at least 1Mbps, and in some cases more.

If the object was uncached the throughput through the caches was poor, certainly well below the 1Mbps required for smooth playback. Once the object had been cached subsequent requests were fine. If the caches were bypassed (by serving the content on a different port) the throughput was fine.

The problem turned out to be the caches using too small a TCP window size for the latency between Auckland and the US. The TelstraClear guys were able to tune this and it's all good now :)

I think the problem can be compounded because the objects in question are not requested that frequently and are very large (50MB+) so are good candidates to be flushed from the cache in favour of more "valuable" content. Also, if the user experience is poor the users are unlikely to watch to the end of the video so the cache may not have downloaded the object before the user gives up and the cache may chose not to store partial objects.

Do you believe this could become and issue with the new Telecom caches?

Thanks,

Dylan


On Wed, 2009-08-12 at 10:31 +1200, Paul Tinson wrote:

 
As a general rule if the content is in a page that gets retrieved by the
cache it will be cached and served from the cache to subsequent
requests.
This includes mp3 files if they are an embedded object.
 
If the mp3 is a single file then I would not expect it to be cached in
parts, so it should not be missing pieces. If it's a streaming mp3 that
may be different and if you supply an example URL I can check this.
 
If you don't want it cached or want to control the time we keep it in
cache then you can use cache control directives and expiry meta tags in
the page.
 
At this point in time we have not enabled caching of streaming media. If
you have a specific example URL please send it to me and I can double
check though. If we have cached it I will look into why.
 
I am happy to look into specific examples of issues, but if you have a
wider service effecting issues please continue to use the helpdesk as
this will result in calls being handled correctly and not left
unattended on the list.
 
Hope this answers your questions.
 
Regards
 
Paul
 
 
 
-----Original Message-----
From: Richard Hulse [mailto:Richard.Hulse@radionz.co.nz] 
Sent: Wednesday, 12 August 2009 9:00 a.m.
To: nznog; Paul Tinson
Subject: Re: [nznog] Telecom International HTTP Caching
 
Hi Paul,
 
I'll ask this on the list, as there are quite a few (other) audio and
video content providers here...
 
How will the cache handle MP3s that are served via HTTP?
 
Is this content you want to cache? 
 
Should we be setting some sort of header to make it work better?
 
Willl you also be caching on-demand Windows Media content?
 
I ask because I have noticed that some of our visitors complain of Mp3
audio that is truncated or has bits missing out of the middle. It seems
to clear itself after a few hours.
 
cheers,
 
Richard Hulse
Webmaster
Radio NZ
 
 
_______________________________________________
NZNOG mailing list
NZNOG@list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog