locked
Singapore computer connecting to California CDN instead of Singapore CDN RRS feed

  • 질문

  • My CDN address is https://az647590.vo.msecnd.net/. My blob is located in Singapore.

    When connecting from Singapore, the CDN resolves to 192.229.145.200, which is located at California. As a result, it takes 170 seconds to download a 90 MB file. Downloading the blob directly takes only 70 seconds.

    Not sure if this is a similar issue to http://social.technet.microsoft.com/Forums/en-US/8f9701c5-afe9-4408-9c86-386b5236c6af/azure-cdn-very-slow-from-indonesia?forum=windowsazuredata

    2014년 8월 1일 금요일 오전 4:09

답변

  • So only the latency data is taken into account when choosing CDN?

    The speed of transfer from California is 41% of what I can get from Singapore (170 vs 70 seconds). Choosing California CDN is absurd! This is definitely a bug. Please create a ticket. Thank you.

    Follow up by Chun Siong in Microsoft Singaopre

    I’ve managed to find out the root cause. The IP address 192.229.145.200 is in Singapore. But when you use online tools to do a lookup, it will resolve to California as when we initially purchased the IP Address Range, it was tied to our HQ in US. In short the IP lookup tool is not updated with the datacenter’s location. Hope this clears up any issues.

    Those IP lookup tools are not accurate.  They are essentially just using registration databases, so they only report wherever that IP address happened to be registered (which is usually the corporate headquarters of whoever owns that IP address).

    If your customer is in Singapore and accessing blob storage in the Singapore datacenter then it is very likely that they could be getting better throughput directly to blob storage rather than from CDN.  It all depends on the ISP’s peering relationships with Microsoft and EdgeCast in that region.  Have your customer go to http://azurespeedtest.azurewebsites.net/ for a quick test on which datacenter/CDN is fastest for them.

    Also make sure that the customer is correctly caching the blobs so that they can be served from the CDN.  If you check the response headers you should see both of the following (after the 2<sup>nd</sup> request to the CDN server):

    Server: ECAcc (ftw/FABE)

    X-Cache: HIT

    If you don’t see those headers then it means the cache control headers are incorrect on the blobs and the CDN has to fetch from origin every time.

    All these things aside,

    The complaint I should escalate here is regarding why is it slower to download from CDN than directly right?

    • 답변으로 표시됨 Li Huan 2014년 8월 20일 수요일 오후 3:48
    • 편집됨 Li Huan 2014년 9월 29일 월요일 오후 1:54 Follow up
    2014년 8월 9일 토요일 오후 3:22

모든 응답

  • Hi Li,

    You also use "tracert" commend to get the router list.

    Like this :

    tracert -d az647590.vo.msecnd.net

    Please share the results for the further support.

    Regards,

    Will


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    • 답변으로 제안됨 Syed Irfan Hussain 2014년 8월 1일 금요일 오전 9:31
    • 답변으로 제안 취소됨 Li Huan 2014년 8월 9일 토요일 오후 3:22
    2014년 8월 1일 금요일 오전 8:49
  • Hello Li Huan,

    The issue seems to be similar to the thread you have mentioned. There appears to be some latency when accessing the CDN for the first time.
    Your question about Singapore content conneting to California CDN. A Azure CDN customer's traffic may not be served out of the physically "closest" node; many factors are involved including routing and peering,
    Internet "weather", and node capacity and availability.

    You can refer to this article for more information: http://msdn.microsoft.com/library/azure/gg680302.aspx

    Also you can please share the tracert results for further investigation. You can go to the command prompt and enter

    tracert www.az647590.vo.msecnd.net

    This will trace down the path and the time taken from each node. This can help us figure out where the exact delay or the latency is.

    Thanks,
    Syed Irfan Hussain

    2014년 8월 1일 금요일 오전 9:31
  • Tracing route to cs1.wpc.v0cdn.net [192.229.145.200]
    over a maximum of 30 hops:

      1    <1 ms    <1 ms    <1 ms  192.168.1.1
      2     2 ms     2 ms     2 ms  172.24.0.1
      3    18 ms     2 ms     2 ms  192.168.255.2
      4    28 ms     3 ms     3 ms  103.6.148.29
      5     3 ms     3 ms     3 ms  202.79.197.67
      6     4 ms     4 ms     4 ms  192.229.145.200

    Trace complete.

    The 5th node is in Singapore (Equinix Asia Pacific Pte Ltd). However, the 6th is California (Edgecast Networks Inc.)

    2014년 8월 1일 금요일 오전 10:23
  • Hello Li Huan,

    I see that from the Tracert results that it is evident that the hop from the Singapore to the California data center is fast and there is no latency.

    If you need detailed analysis on this, I suggest that you contact Windows Azure Techinical Support. You can follow the link below to contact Support:

    http://azure.microsoft.com/en-us/support/options/

    Thanks,
    Syed Irfan hussain

    2014년 8월 9일 토요일 오전 5:22
  • So only the latency data is taken into account when choosing CDN?

    The speed of transfer from California is 41% of what I can get from Singapore (170 vs 70 seconds). Choosing California CDN is absurd! This is definitely a bug. Please create a ticket. Thank you.

    Follow up by Chun Siong in Microsoft Singaopre

    I’ve managed to find out the root cause. The IP address 192.229.145.200 is in Singapore. But when you use online tools to do a lookup, it will resolve to California as when we initially purchased the IP Address Range, it was tied to our HQ in US. In short the IP lookup tool is not updated with the datacenter’s location. Hope this clears up any issues.

    Those IP lookup tools are not accurate.  They are essentially just using registration databases, so they only report wherever that IP address happened to be registered (which is usually the corporate headquarters of whoever owns that IP address).

    If your customer is in Singapore and accessing blob storage in the Singapore datacenter then it is very likely that they could be getting better throughput directly to blob storage rather than from CDN.  It all depends on the ISP’s peering relationships with Microsoft and EdgeCast in that region.  Have your customer go to http://azurespeedtest.azurewebsites.net/ for a quick test on which datacenter/CDN is fastest for them.

    Also make sure that the customer is correctly caching the blobs so that they can be served from the CDN.  If you check the response headers you should see both of the following (after the 2<sup>nd</sup> request to the CDN server):

    Server: ECAcc (ftw/FABE)

    X-Cache: HIT

    If you don’t see those headers then it means the cache control headers are incorrect on the blobs and the CDN has to fetch from origin every time.

    All these things aside,

    The complaint I should escalate here is regarding why is it slower to download from CDN than directly right?

    • 답변으로 표시됨 Li Huan 2014년 8월 20일 수요일 오후 3:48
    • 편집됨 Li Huan 2014년 9월 29일 월요일 오후 1:54 Follow up
    2014년 8월 9일 토요일 오후 3:22
  • Hello Li Huan,

    Thank you for your response. You can click on the link in the previous post to contact us and create a Support Ticket.

    Thanks,
    Syed Irfan Hussain

    • 답변으로 제안됨 Lakshmeesha Phaneesha 2014년 8월 20일 수요일 오후 2:30
    • 답변으로 표시됨 Lakshmeesha Phaneesha 2014년 8월 20일 수요일 오후 2:30
    • 답변으로 표시 취소됨 Li Huan 2014년 8월 20일 수요일 오후 3:48
    • 답변으로 제안 취소됨 Li Huan 2014년 8월 20일 수요일 오후 3:48
    2014년 8월 11일 월요일 오후 3:30