locked
Verizon CDN - Multiple requests to origin server from same CDN IP address within the same second for the same image RRS feed

  • Question

  • I have a CDN endpoint configured to retrieve data (images) from a custom origin server. I recently ran a simulated load test of 2000 virtual users requesting all (282) images at various times over the course of the test. Cache-control for the images is set at 2 minutes. What I notice is when there are a large number of requests for the same image occurring during the test I am seeing multiple requests from the same CDN IP address to the origin server all within the same second (again for the same image).

    I'm just trying to understand why there are so many requests from the CDN for the same image from the same CDN IP address within the same second and sometimes within seconds of the previous request. I had assumed there would only have been one request from the same CDN IP unless there were errors.

    Friday, November 11, 2016 5:12 PM

Answers

  • I understand from another support call that the CDN doesn't cache until a full response is retrieved from the origin server. In the case of our testing we were generating around 8000 requests/sec and seeing a few dozen requests for the same image (320x240 jpg) from the same IP. The images are real-time surveillance images that are made available every 2 minutes. The origin server actually builds images of requested sizes and caches those as needed (based on requests received) locally at the origin server. It appears with large numbers of requests the response time of the origin server is slow enough that a full response is not generated in time thus causing the multiple requests per second from the same CDN IP.

    I did not know about the 2nd hit caching behavior, but it makes sense. The pre-load functionality is probably not useful in this use-case since the images are changing every 2 - 5 minutes. This would mean a pre-load request at a similar rate which is just doesn't seem to make much sense.

    Thanks for the info on the response headers. I had already been reviewing the details of the request/response and picked up on these being there.

    At this point the behavior of the CDN requests is understood. However, it would certainly be nice to be able to configure the CDN to serve from its cache in these high request situations. In other words, a CDN edge server would know it is currently making a request to the origin server for the resource and if there is something already cached it would be served regardless of the expiration time or possible return a 304. Obviously if the item being requested isn't in the cache (first use) then all the requests would have to be forwarded to the origin server until a full response has been received and cached. Again, this behavior would be configurable with the CDN management UI.

    Thanks for your time in responding.

    • Marked as answer by Cre8More Saturday, November 12, 2016 7:59 AM
    Saturday, November 12, 2016 7:58 AM

All replies

  • How many requests are you seeing and what is the size of the image that you have stored on the origin? Also would be helpful if you can provide both sample URL that you used for testing and HTTP response header seen for your requests. By default Azure CDN from Verizon has 2nd hit caching behavior which results in files not being cached until they are at least two requests for the file. To minimize hits on your origin you can also use load functionality - available via either API or from the Azure Portal UX. This will result in your image being cached on every POP by default.

    Note that you can determine from the response header's if content is being cached. You will see both an X-Cache: Hit header along with a Server header with format of Server: ECAcc (xxx/YYYY).

    Friday, November 11, 2016 6:30 PM
  • I understand from another support call that the CDN doesn't cache until a full response is retrieved from the origin server. In the case of our testing we were generating around 8000 requests/sec and seeing a few dozen requests for the same image (320x240 jpg) from the same IP. The images are real-time surveillance images that are made available every 2 minutes. The origin server actually builds images of requested sizes and caches those as needed (based on requests received) locally at the origin server. It appears with large numbers of requests the response time of the origin server is slow enough that a full response is not generated in time thus causing the multiple requests per second from the same CDN IP.

    I did not know about the 2nd hit caching behavior, but it makes sense. The pre-load functionality is probably not useful in this use-case since the images are changing every 2 - 5 minutes. This would mean a pre-load request at a similar rate which is just doesn't seem to make much sense.

    Thanks for the info on the response headers. I had already been reviewing the details of the request/response and picked up on these being there.

    At this point the behavior of the CDN requests is understood. However, it would certainly be nice to be able to configure the CDN to serve from its cache in these high request situations. In other words, a CDN edge server would know it is currently making a request to the origin server for the resource and if there is something already cached it would be served regardless of the expiration time or possible return a 304. Obviously if the item being requested isn't in the cache (first use) then all the requests would have to be forwarded to the origin server until a full response has been received and cached. Again, this behavior would be configurable with the CDN management UI.

    Thanks for your time in responding.

    • Marked as answer by Cre8More Saturday, November 12, 2016 7:59 AM
    Saturday, November 12, 2016 7:58 AM
  • There is additional cache control capabilities available via the rules engine available in Azure CDN from Verizon Premium. With Azure CDN from Verizon Standard just a limited set of capabilities that are possible via the rules engine are exposed. Via Azure CDN from Verizon Premium you can access the rules engine by clicking on the manage button in the CDN profile. This will take you to the CDN Supplemental Portal. Under the HTTP Large tab select the rules engine option. Rules are created based on specific matches and then associating a specific behavior/feature with this match. Creating a rule that enables the "Partial Cache Sharing" feature will result in the CDN being able to respond to another request for the same asset as soon as the asset starts loading into the CDN cache. When enabled the CDN is able to respond to additional requests for the same asset from the "growing" partial resource being pulled into the cached as a result of the initial client request. This avoids additional requests to the origin for the same asset.
    Monday, November 14, 2016 8:52 PM