2014-06-05 19 views
6

Tôi đang xây dựng ứng dụng web EF6 ở Azure và tôi đang sử dụng Azure Cache. Tôi đang thử nghiệm các cuộc gọi đến dịch vụ WCF của mình và tôi nhận được thời gian phản hồi cực kỳ thất thường - từ 300ms đến 15 giây!Thời gian phản hồi liên tục của bộ nhớ cache Azure từ dịch vụ REST WCF

tôi cấu hình mã của tôi theo và nó chạy tốt tại địa phương

Tôi đã sửa lỗi từ xa và tôi có thể thấy rằng chìa khóa bộ nhớ cache đã được tìm thấy và các dữ liệu được nhận được gọi là từ bộ nhớ cache, vì vậy tôi đấu tranh để hiểu tại sao có sych một sự thay đổi rất lớn trong thời gian phản ứng. Hầu hết thời gian là 5 + giây rõ ràng là waaay quá lâu.

Ví dụ mà tôi đã được thử nghiệm như sau:

dịch vụ WCF GET yêu cầu: http://feniksdev-staging.azurewebsites.net/EkckoNewsService.svc/getFriends

 // Cache client configured by settings in application configuration file. 
     public DataCacheFactory cacheFactory = new DataCacheFactory(); 
     public DataCache _cache; 
     public DataCache cache 
     { 
      get 
      { 
       if (_cache == null) 
        _cache = cacheFactory.GetDefaultCache(); 

       return _cache; 
      } 
      set { } 
     } 
... 
... 

[OperationContract] 
    [System.ServiceModel.Web.WebGet(ResponseFormat = WebMessageFormat.Json, UriTemplate = "/getFriends")] 
    public string getFriends() 
    { 
     string cachekey = "getFriends/{" + user.Id + "}"; 
     object result = cache.Get(cachekey); 
     if (result == null) 
     { 
      using (EkckoContext entities = new EkckoContext()) 
      { 
       var frnds = entities.UserConnections.Where(uc => uc.UserId == user.Id).Select(uc => new { Name = uc.Friend.Username }).ToList(); 
       JsonSerializerSettings jsonSettings = new JsonSerializerSettings { PreserveReferencesHandling = PreserveReferencesHandling.Objects }; 
       string json = JsonConvert.SerializeObject(frnds, jsonSettings); 
       cache.Add(cachekey, json); 
       return json; 
      } 
     } 
     else 
     { 
      return (string)result; 
     } 
    } 

UserConnection là một bảng đơn giản trong db của tôi và hiện không có dữ liệu, do đó cuộc gọi trả về một mảng JSON trống. user là đối tượng Phiên và hiện mặc định là 1 cho user.Id

Khi từ xa gỡ lỗi này, đối tượng được tìm thấy trong bộ nhớ cache và đối tượng được lưu trong bộ nhớ cache được trả về. Vì vậy, tất cả đều tốt, ngoại trừ thời gian phản ứng vẫn thay đổi theo hệ số 20 (300ms - 6sec).

Khi xa gỡ lỗi một trong những phương pháp dịch vụ web khác, tôi đã nhận lỗi sau khi cố gắng truy cập vào các đối tượng được lưu trữ bằng cách sử dụng phím tương ứng (object result = cache.Get(cachekey);):

{ "ERRORCODE: SubStatus: Có một Hãy thử lại sau. (Một hoặc nhiều máy chủ bộ nhớ cache được chỉ định không khả dụng, có thể do mạng bận hoặc máy chủ gây ra. Đối với cụm bộ nhớ cache tại chỗ, cũng xác minh các điều kiện sau đây. và kiểm tra xem AppFabric Caching Service có được phép thông qua tường lửa trên tất cả các host cache hay không. kích thước đối tượng được gửi từ máy khách.). Các thông tin khác: Các khách hàng đã cố gắng để giao tiếp với máy chủ: net.tcp: //ekckodev.cache.windows.net:. 22.238 "}

sau đó tôi đặt MaxBufferSize trong cấu hình của tôi như sau:

.
<configSections> 
<section name="dataCacheClients" type="Microsoft.ApplicationServer.Caching.DataCacheClientsSection, Microsoft.ApplicationServer.Caching.Core" allowLocation="true" allowDefinition="Everywhere" /> 
    <section name="cacheDiagnostics" type="Microsoft.ApplicationServer.Caching.AzureCommon.DiagnosticsConfigurationSection, Microsoft.ApplicationServer.Caching.AzureCommon" allowLocation="true" allowDefinition="Everywhere" /> 
</configSections> 
... 
... 
<system.web> 
... 
... 
<caching> 
     <outputCache defaultProvider="AFCacheOutputCacheProvider"> 
     <providers> 
      <add name="AFCacheOutputCacheProvider" type="Microsoft.Web.DistributedCache.DistributedCacheOutputCacheProvider, Microsoft.Web.DistributedCache" cacheName="default" dataCacheClientName="default" applicationName="AFCacheOutputCache" /> 
     </providers> 
     </outputCache> 
    </caching> 
</system.web> 
    .... 
    .... 
    ... 
     <dataCacheClients> 
     <dataCacheClient name="default"> 
      <autoDiscover isEnabled="true" identifier="ekckodev.cache.windows.net" /> 
      <localCache isEnabled="true" sync="TimeoutBased" objectCount="100000" ttlValue="300" /> 
      <securityProperties mode="Message" sslEnabled="false"> 
      <messageSecurity authorizationInfo="xxxxxxxxxxxxxxxxxxxxxxx" /> 
      </securityProperties> 
      <transportProperties connectionBufferSize="131072" maxBufferPoolSize="268435456" 
           maxBufferSize="8388608" maxOutputDelay="2" channelInitializationTimeout="60000" 
           receiveTimeout="600000"/> 
     </dataCacheClient> 
     </dataCacheClients> 

Nhưng tôi vẫn nhận được thời gian đáp ứng thất thường như vậy - đặc biệt là khi đánh cuộc gọi dịch vụ tương tự lặp đi lặp lại

Sau khi thêm cấu hình MaxBufferSize, các cuộc gọi bộ nhớ cache vẫn hit-and-miss một số lấy đối tượng; khác. lần tôi nhận được ngoại lệ tương tự, tuy nhiên cổng là khác nhau

" ... Các khách hàng đã cố gắng để giao tiếp với máy chủ: net.tcp: //ekckodev.cache.windows.net:. 22.233 "}"

Phải chăng đây là một bức tường lửa vấn đề? Nếu vậy, làm cách nào để mở các cổng thích hợp?

Tôi cũng chỉ có ngoại lệ sau khi instantiating đối tượng DataCache:

_cache = cacheFactory.GetDefaultCache();

ERRORCODE: SubStatus: Có một sự thất bại tạm thời. Vui lòng thử lại sau. (Một hoặc nhiều máy chủ bộ nhớ cache được chỉ định không khả dụng, có thể do mạng bận hoặc máy chủ gây ra. Đối với các cụm bộ nhớ cache tại chỗ, cũng xác minh các điều kiện sau. Đảm bảo rằng quyền bảo mật đã được cấp cho tài khoản khách hàng này và kiểm tra rằng Caching Service AppFabric được phép qua tường lửa trên tất cả các host cache. Ngoài ra MaxBufferSize trên máy chủ phải lớn hơn hoặc bằng với kích thước đối tượng serialized gửi từ khách hàng.)

Bất kỳ suy nghĩ về lý do tại sao Tôi nhận được kết quả như vậy? nó chắc chắn không nhanh hơn với bộ nhớ cache hơn WIHTOUT nó, do đó, nó xuất hiện có một số loại độ trễ trong bộ nhớ cache mà không có vẻ ...

Cảm ơn trước sự giúp đỡ nào!

CẬP NHẬT: Sau khi thực hiện một số tìm kiếm nhiều hơn, có vẻ như tôi không phải là người duy nhất với vấn đề này: poor performance with azure cache

tôi thấy khó để tin rằng đây là việc thực hiện tôi nên mong đợi

CẬP NHẬT 2 Tôi đã nhận xét tất cả mã liên quan đến bộ nhớ cache từ dịch vụ của mình và chạy lại các kiểm tra tương tự. Thời gian phản hồi thấp hơn đáng kể KHÔNG CÓ bộ nhớ cache! các calla trung bình "getFriends" khoảng 250ms sẽ không có cache, nhưng đỉnh cao hơn 5 giây với cache. Phương pháp khác của tôi tìm nạp khoảng 4kb dữ liệu, đã đạt tới mức cao nhất là 20 giây với bộ nhớ cache và bây giờ là trung bình khoảng 2 giây KHÔNG có bộ nhớ cache.

Một lần nữa: Tôi thấy khó để tin rằng đây là việc thực hiện tôi nên mong đợi

CẬP NHẬT 3 Bây giờ tôi đã bị tháo dỡ Azure cache ủng hộ MemoryCache. Ví dụ hay, here Các cuộc gọi dịch vụ của tôi hiện liên tục sử dụng xấp xỉ 300ms trong trình duyệt.

Tôi đã mở một vé với sự hỗ trợ của Microsoft Azure liên quan đến Azure Cache, vì vậy tôi sẽ cập nhật bài đăng này khi họ liên lạc và tôi đã hỏi tại sao bộ nhớ cache của họ quá rác rưởi. Ngay khi niềm tin của tôi vào Microsoft đã leo lên:/

+0

Bạn có chắc chắn rằng bộ nhớ cache là thành phần chậm không? Dow đã làm bạn xác định điều đó? – usr

+0

Vâng - Tôi chạy kiểm tra tốc độ trước, trong và sau khi triển khai Azure Cache. Và sau đó một lần nữa sau khi thực hiện MemCache. Như đã nói, tôi cũng đã sửa lỗi từ xa để chắc chắn rằng nó đã nhận được dữ liệu từ bộ nhớ cache chứ không phải DB. Biến duy nhất đã thay đổi là bộ nhớ cache. Có thể vấn đề là do lỗi cấu hình, nhưng tôi đã kiểm tra lại cấu hình của mình dựa trên các ví dụ của MS –

+0

Tôi muốn cấu hình trang web để tìm ra thời gian được dành cho nội bộ của bộ nhớ cache. Ngăn xếp thường đưa ra những manh mối quan trọng cho những gì đang diễn ra chỉ bằng các tên hàm. Chỉ cần tạm dừng trình gỡ lỗi 10 lần trong khi có tải trên trang web. Nó sẽ rất có khả năng dừng lại trong thành phần chậm phần lớn thời gian. Nhìn vào ngăn xếp (bao gồm cả mã bên ngoài). – usr

Trả lời

0

Có vẻ như bạn đã đến đúng kết luận, là không sử dụng Azure Managed Cache. Khoảng 6 tháng trước, Microsoft bắt đầu đề xuất tất cả các phát triển mới được thực hiện đối với việc cung cấp bộ nhớ đệm dựa trên Redis của họ trong Azure.

We recommend all new developments use Azure Redis Cache.

Kỳ lạ thay, họ không hiển thị các tùy chọn để tạo ra một bộ nhớ cache Redis trong các trang web quản lý Azure 'cũ' (manage.windowsazure.com), nhưng họ không có nó trong "xem trước" Azure management portal.

Các vấn đề liên quan