Results 1 to 3 of 3

Thread: Cloudfront, EC2 and S3 optimization

  1. #1

    Default Cloudfront, EC2 and S3 optimization

    Hi there ... I'm wondering if you have a best practice document for streaming out of EC2 instance as origin, Cloudfront and using S3 buckets
    I have the workflow working fine, but the startup time of a VOD playback is more than 6 seconds, which I consider extremely high.
    I'd like to know if you have best practices to remove this latency
    Does Wowza starts serving the video as soon as it have some content, or it requires to have access to all content in memory before it serves it out?

    Thanks in advance

    Note: when video is cached, startup is not that high ... but sometimes people don't watch all content, so not all content is cached, and when you fast forward, again it takes more than 6 secs to playback

  2. #2
    Join Date
    May 2013
    Posts
    681

    Default

    Hello

    You can preload more of your content to expedite the delivery time by using our MediaCache Preload Module.

    Thanks,

    Matt

  3. #3

    Default

    Hi,

    There are possibly a few causes for the issues you are seeing and there are some tests that you can do to see where the problem is.

    The issue may be with the delivery time between S3 and Wowza or between Wowza and the CloudFront server. Bot Wowza and the CloudFront server will be caching the content so it will get quicker as it is cached closer to you.

    First, confirm if the CloudFront server is causing the initial delay. To do this, stream a file via CloudFront from a regular VOD application that isn't HTTP Origin or MediaCache enabled. eg: sample.mp4 from the default VOD application. Because it isn't HttpOrigin enabled, Wowza will attach session id's to the requests which will prevent CloudFront from caching it and the file will already exist on the Wowza server so it will be as if it was already cached from S3 by Media Cache.

    If the load time is slow, try streaming the same file directly from the Wowza server application. If the CloudFront stream is a lot slower to load than the direct stream then it is the network between CloudFront and the EC2 server that is causing the delays and there isn't a lot that can be done apart from possibly making the segment sizes smaller so that they are retrieved quicker.

    To do this, there is are properties that can be set in the application configuration that controls the target segment size. The default is 10 second segments and we have found some improvements with lowering this value to create smaller segments which will download quicker, allowing the stream to start quicker and seek quicker. The target duration should be multiples of the Key Frame interval however if it doesn't match exactly, Wowza will make the actual segment sizes to the closest key frame.

    Path Name Type Value Description
    /Root/Application/HTTPStreamer cupertinoChunkDurationTarget Integer 6000 Apple HLS default 10000 (10 seconds)
    /Root/Application/HTTPStreamer sanjoseChunkDurationTarget Integer 6000 Adobe HDS default 10000 (10 seconds)

    Run the same test with an application that is HttpOrigin enabled (but not Media Cache enabled) and compare the results. This one will get cached by CloudFront so you should expect to see an improvement after the stream is initially cached.

    If you don't see any improvements here then check the load time between Wowza and S3. To do this, you will need to enable http request debug logging in your Media Cache Source configuration. Add the following property to you Media Cache Source properties. You will have to restart Wowza after changing the properties and don't forget to disable it when you have finished testing.

    Path Name Type Value Description
    /Root/MediaCacheSources/MediaCacheSource debugHTTPRequests Boolean true Debug HTTP requests between Wowza and Media Cache source

    You will need to examine the Wowza log files and when a stream is requested, you should see a bunch of requests to the Media Cache which will be grouped together. Each group will be a single segment and you will be looking at the time taken for all of the requests for a segment to return. What we have generally found is that the request only take a few milliseconds to return so this may not be the cause of the delays.

    You may see some improvement by increasing the defaultBlockSize setting in the Media Cache Source configuration. This will make less (but larger) requests for each segment and allow S3 to better utilize the bandwidth between S3 and Wowza.

    When testing caching, you may need to flush the item from the cache each time or restart Wowza to flush it.

    Don't forget to transfer any settings to your production application.

    Roger.

Similar Threads

  1. EC2 Instances: Purpose of CloudFront?
    By tirapell in forum Wowza Media Server 3 for Amazon EC2 Discussion
    Replies: 9
    Last Post: 01-06-2014, 08:37 AM
  2. Wowza EC2 + Cloudfront = it works !
    By azrilnazli in forum Wowza Media Server 3 for Amazon EC2 Discussion
    Replies: 13
    Last Post: 12-09-2013, 04:37 PM
  3. Use WOWZA-EC2 with Amazon Cloudfront
    By nkkrishna in forum Wowza Media Server 3 for Amazon EC2 Discussion
    Replies: 12
    Last Post: 03-12-2013, 08:13 AM
  4. EC2 + Cloudfront + HTTPProvider problem
    By drHatchet in forum General Forum
    Replies: 0
    Last Post: 02-01-2013, 04:00 PM
  5. Ingest point optimization for publisher on multi-instance EC2 setup
    By videodoctor in forum Wowza Media Server 3 for Amazon EC2 Discussion
    Replies: 2
    Last Post: 02-07-2012, 08:05 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •