Phân tích hiệu suất bằng Azure CDN?

Question

Tôi đã thử nghiệm khá một chút với CDN từ Azure, và tôi nghĩ tôi đã về nhà an toàn sau khi thiết lập thành công bằng cách sử dụng vai trò web.

Tại sao lại là vai trò web?

Vâng, tôi muốn những lợi ích của các tiêu đề nén và bộ nhớ đệm mà tôi đã không thành công khi sử dụng cách viết hoa bình thường. Và như là một tiền thưởng thêm; các hạn chế phân biệt chữ hoa chữ thường cũng bị loại bỏ.

Đủ với lựa chọn phục vụ CDN; trong khi tất cả nội dung trước đây được phân phối từ cùng một tên miền, giờ đây tôi phân phối nhiều hoặc ít hơn tất cả nội dung "tĩnh" từ cdn.cuemon.net. Về lý thuyết, điều này sẽ cải thiện hiệu suất vì các trình duyệt song song có thể lan truyền nội dung thu thập trên các miền "nhiều" so với một tên miền duy nhất.

Thật không may điều này đã dẫn đến sự suy giảm trong hoạt động mà tôi tin rằng đã làm với số hobs trước khi nội dung đang được phục vụ (sử dụng lệnh tracert):

C:\Windows\system32>tracert -d cdn.cuemon.net 

Tracing route to az162766.vo.msecnd.net [94.245.68.160] 
over a maximum of 30 hops: 

    1  1 ms  1 ms  1 ms 192.168.1.1 
    2 21 ms 21 ms 21 ms 87.59.99.217 
    3 30 ms 30 ms 31 ms 62.95.54.124 
    4 30 ms 29 ms 29 ms 194.68.128.181 
    5 30 ms 30 ms 30 ms 207.46.42.44 
    6 83 ms 61 ms 59 ms 207.46.42.7 
    7 65 ms 65 ms 64 ms 207.46.42.13 
    8 65 ms 67 ms 74 ms 213.199.152.186 
    9 65 ms 65 ms 64 ms 94.245.68.160 

C:\Windows\system32>tracert cdn.cuemon.net 

Tracing route to az162766.vo.msecnd.net [94.245.68.160] 
over a maximum of 30 hops: 

    1  1 ms  1 ms  1 ms 192.168.1.1 
    2 21 ms 22 ms 20 ms ge-1-1-0-1104.hlgnqu1.dk.ip.tdc.net [87.59.99.217] 
    3 29 ms 30 ms 30 ms ae1.tg4-peer1.sto.se.ip.tdc.net [62.95.54.124] 
    4 30 ms 30 ms 29 ms netnod-ix-ge-b-sth-1500.microsoft.com [194.68.128.181] 
    5 45 ms 45 ms 46 ms ge-3-0-0-0.ams-64cb-1a.ntwk.msn.net [207.46.42.10] 
    6 87 ms 59 ms 59 ms xe-3-2-0-0.fra-96cbe-1a.ntwk.msn.net [207.46.42.50] 
    7 68 ms 65 ms 65 ms xe-0-1-0-0.zrh-96cbe-1b.ntwk.msn.net [207.46.42.13] 
    8 65 ms 70 ms 74 ms 10gigabitethernet5-1.zrh-xmx-edgcom-1b.ntwk.msn.net [213.199.152.186] 
    9 65 ms 65 ms 65 ms cds29.zrh9.msecn.net [94.245.68.160] 

Như bạn có thể nhìn thấy từ dấu vết trên tuyến đường, tất cả nội dung bên ngoài bị trì hoãn trong một thời gian. Nó là đáng chú ý, rằng dịch vụ Azure được thiết lập ở Bắc Âu và tôi định cư tại Đan Mạch, tại sao tuyến đường này là một chút .. hmm .. trên đầu trang?

Một vấn đề khác có thể là vai trò web là hai trường hợp cực nhỏ; Tôi đã không tìm thấy thời gian chưa thử với hai trường hợp nhỏ, nhưng tôi biết rằng Microsoft giới hạn các trường hợp nhỏ thêm vào một mạng 5Mb/s, nơi nhỏ và ở trên có 100Mb/s.

Tôi cũng không chắc liệu điều này có phù hợp với CDN hay không.

Dù sao - bất kỳ trợ giúp và/hoặc giải thích nào được đánh giá cao.

Và hãy để tôi nói, rằng tôi rất hài lòng với nền tảng Azure - Tôi chỉ tò mò về các vấn đề được đề cập ở trên.

Cập nhật

New tracert mà không có sự lựa chọn -d.

Được lấy cảm hứng từ user728584 Tôi đã nghiên cứu và tìm thấy bài viết này, http://blogs.msdn.com/b/scicoria/archive/2011/03/11/taking-advantage-of-windows-azure-cdn-and-dynamic-pages-in-asp-net-caching-content-from-hosted-services.aspx, mà tôi sẽ điều tra thêm về kiểm soát bộ nhớ cache công cộng và CDN.

Điều này không giải thích hiện tượng đếm hoa bia quá mức, nhưng tôi hy vọng một chuyên gia mạng có kỹ năng có thể giúp đúc ánh sáng cho vấn đề này.

Hãy yên tâm, rằng tôi sẽ giữ cho bạn được đăng theo những phát hiện của tôi.

Answer 1

Không nêu rõ nhưng tôi cho rằng bạn đã đặt tiêu đề HTTP Cache-Control thành số lớn để nội dung của bạn không bị xóa khỏi CDN Cache và được phân phát từ Bộ nhớ Blob khi bạn thực hiện kiểm tra tracert?

Có khá một vài máy chủ cạnh gần bạn vì vậy tôi mong chờ nó hoạt động tốt hơn: http://msdn.microsoft.com/en-us/library/windowsazure/gg680302.aspx

Maarten Balliauw 'Windows Azure CDN Node Locations' có một bài viết tuyệt vời về cách sử dụng và sử dụng trường hợp cho CDN (điều này có thể giúp đỡ): http://acloudyplace.com/2012/04/using-the-windows-azure-content-delivery-network/

Không chắc rằng sẽ giúp chút nào, thú vị ...

Answer 2

được rồi, sau khi tôi đã thực hiện công bộ nhớ đệm kiểm soát tiêu đề, CDN dường như làm gì được mong đợi; cung cấp nội dung từ x-số nút trong cụm CDN.

Ở trên có những hạn chế mà nó có kinh nghiệm - nó không được đo để xác nhận cụ thể.

Tuy nhiên, liên kết này ủng hộ lý thuyết của tôi: http://msdn.microsoft.com/en-us/wazplatformtrainingcourse_windowsazurecdn_topic3,

Thời gian-to-live (TTL) thiết lập cho một điều khiển blob trong bao lâu một máy chủ cạnh CDN trả về một bản sao của tài nguyên lưu trữ trước khi yêu cầu một bản sao mới từ nguồn của nó trong kho lưu trữ blob. Khi khoảng thời gian này hết hạn, yêu cầu mới sẽ buộc máy chủ CDN truy xuất lại tài nguyên từ blob gốc, tại thời điểm này nó sẽ lưu lại bộ nhớ.

Thách thức được giả định của tôi là gì; tài nguyên tham chiếu CDN giữ gộp nhóm gốc.

Ngoài ra, tín dụng cũng phải được cung cấp cho liên kết này (do người dùng728584 cung cấp); http://blogs.msdn.com/b/scicoria/archive/2011/03/11/taking-advantage-of-windows-azure-cdn-and-dynamic-pages-in-asp-net-caching-content-from-hosted-services.aspx.

Và liên kết cuối cùng cho bây giờ: http://blogs.msdn.com/b/windowsazure/archive/2011/03/18/best-practices-for-the-windows-azure-content-delivery-network.aspx

Đối với các trang ASP.NET, hành vi mặc định là để thiết lập kiểm soát bộ nhớ cache để tin. Trong trường hợp này, Windows Azure CDN sẽ không lưu trữ nội dung này. Để ghi đè hành vi này, hãy sử dụng đối tượng Response để thay đổi các thiết lập kiểm soát bộ nhớ cache mặc định.

Vì vậy, kết luận của tôi cho đến nay cho câu đố nhỏ này là bạn phải chú ý đến bộ nhớ cache của bạn (thường được đặt thành riêng tư vì lý do hiển nhiên). Nếu bạn bỏ qua cách tiếp cận vai trò web, TTL là theo mặc định 72 giờ, tại sao bạn có thể không bao giờ trải nghiệm những gì tôi có kinh nghiệm; do đó nó sẽ chỉ làm việc out-of-the-box.

Nhờ user728584 để chỉ cho tôi đúng hướng.