azure cdn edge in japan not responsive

0
votes

I run a webserver (http://www.mycompany.com) in Azure (in West Europe) which displays a lot of images to the users.

This configuration works fine from my client in Sweden. Both small thumbnails and large versions of the images show up, and it is fast.

Users in Japan see the thumbnails (2KB) without problem, but large images (500KB) takes minutes to download, even over high-performant fiber connections. When I comandeered a computer in Japan and forced cdn.mycompany.com to point to 93.184.221.200 (which is Azures edge for Sweden), the same image was downloaded in reasonable speed! It also worked to require the image directly from resizer.mycompany.com or Blob Storage.

I've tried to diagnose this for a week now and don't know how to continue.

  • Is there something wrong with the CDN Edge in Japan?
  • Is the problem that the CDN Edge in Japan is too far from the WebApp in West Europe?
  • Do I have performance issues on the WebApp or Blob Storage that I just havn't realized? (there are a lot of japanese users hitting the website at the same time)

(The urls above are obviously obfuscated)

1
performanceazureazure-cdn

1 Answers

1
votes

There is no simple solution for diagnosing performance issues. Below is generic guidance for investigating performance issues. For additional guidance you would need to provide example URL's and associated http response header data that illustrate the performance issues.

Request the slow performing content using a tool that provides response header data – Chrome Developer Tools, IE Developer Toos, Firebug, Fiddler, Wget, cURL. Verify that the response contains the “Server” header and that it has the format similar to the following “Server: ECAcc (pae/3725)” Overall whenever cached content is being returned from the CDN the Server header will use the following syntax: platform (POP/ID). Additionally, the X-Cache header value will show up with a value of HIT indicating that the content is being cached by the CDN. The CDN by default has 2nd hit caching behavior which results in content being cached only after it has been requested twice from the same POP location. Network issues: Use the traceroute tool to check network issues between the client that is experiencing performance issues and the edge of the CDN. Speed Test: Perform an internet speed test from the client that is experiencing performance issues to determine if the ISP is causing sub-optimal performance.