Redis için Azure Cache yönetimi hakkında SSS

Redis sunucusu TLS'yi yerel olarak desteklemez, ancak Redis için Azure Cache destekler. Redis için Azure Cache bağlanıyorsanız ve istemciniz StackExchange.Redis gibi TLS'yi destekliyorsa TLS kullanın.

Gibi redis-cli Redis araçları TLS bağlantı noktasıyla çalışmaz, ancak Redis için ASP.NET Oturum Durumu Sağlayıcısı duyurulması Önizleme Sürümü blog gönderisindeki yönergeleri izleyerek araçları TLS bağlantı noktasına güvenli bir şekilde bağlamak gibi bir yardımcı program stunnel kullanabilirsiniz.

Redis araçlarını indirme yönergeleri için Redis komutlarını nasıl çalıştırabilirim? bölümüne bakın.

• StackExchange.Redis en iyi yöntemleri
• Yapılandırma ve kavramlar
• Performansı test etme

StackExchange.Redis en iyi yöntemleri

• false olarak ayarlayın AbortConnect , ardından ConnectionMultiplexer'ın otomatik olarak yeniden bağlanmasına izin verin.
• Her istek için yeni bir bağlantı oluşturmak yerine tek, uzun ömürlü ConnectionMultiplexer bir örnek kullanın.
• Redis daha küçük değerlerle en iyi şekilde çalışır, bu nedenle daha büyük verileri birden çok anahtara bölmeyi göz önünde bulundurun. Bu Redis tartışmasında 100 kb büyük olarak kabul edilir. Daha fazla bilgi için bkz . En iyi yöntemler geliştirme.
• Zaman aşımlarını önlemek için ThreadPool ayarlarınızı yapılandırın.
• En az 5 saniyelik varsayılan connectTimeout değerini kullanın. Bu aralık StackExchange.Redis'e bir ağ blip'i varsa bağlantıyı yeniden kurmak için yeterli süre verir.
• Çalıştırdığınız farklı işlemlerle ilişkili performans maliyetlerine dikkat edin. Örneğin, KEYS komut bir O(n) işlemidir ve bundan kaçınılmalıdır. redis.io sitesinde, desteklediği her işlem için zaman karmaşıklığıyla ilgili ayrıntılar bulunur. Her işlemin karmaşıklığını görmek için her komutu seçin.

Yapılandırma ve kavramlar

• Üretim sistemleri için Standart veya Premium Katmanı kullanın. Temel Katman, veri çoğaltma ve SLA bulunmayan tek düğümlü bir sistemdir. Ayrıca en az C1 önbelleği kullanın. C0 önbellekleri genellikle basit geliştirme/test senaryoları için kullanılır.
• Redis'in bellek içi veri deposu olduğunu unutmayın. Daha fazla bilgi için bkz. Redis için Azure Cache veri kaybıyla ilgili sorunları giderme, böylece veri kaybının oluşabileceği senaryoları fark etmeniz.
• Düzeltme eki uygulama ve yük devretmenin neden olduğu bağlantı sinyallerini işleyebilecek şekilde sisteminizi geliştirin.

Performans testi

• Kendi performans testlerinizi yazmadan önce olası aktarım hızına yönelik bir his elde etmek için komutunu kullanarak redis-benchmark.exe başlayın. redis-benchmark TLS'yi desteklemediğinden, testi çalıştırmadan önce Azure portalı üzerinden TLS olmayan bağlantı noktasını etkinleştirmeniz gerekir. Örnekler için bkz. Önbelleğimin performansını nasıl kıyaslayabilirim ve test ederim?
• Test için kullanılan istemci VM,Redis için Azure Cache örneğiniz ile aynı bölgede olmalıdır.
• İstemciniz daha iyi donanıma sahip olduğundan ve en iyi sonuçları vermesi gerektiği için Dv2 VM Serisi'ni kullanmanızı öneririz.
• Seçtiğiniz istemci VM'sinin en az test ettiğiniz önbellek kadar bilgi işlem ve bant genişliği özelliğine sahip olduğundan emin olun.
• Windows kullanıyorsanız istemci makinede VRSS'yi etkinleştirin. Ayrıntılar için buraya bakın.
• Premium katman Redis örnekleri hem CPU hem de Ağ için daha iyi bir donanım üzerinde çalıştığından daha iyi ağ gecikme süresine ve aktarım hızına sahiptir.

• Bu komutların sonucunu tam olarak anlamadığınız sürece tamamlanması uzun süren belirli Redis komutlarını kullanmaktan kaçının. Örneğin, üretimde KEYS komutunu çalıştırmayın. Anahtar sayısına bağlı olarak, döndürülmesi uzun sürebilir. Redis tek iş parçacıklı bir sunucudur ve komutları birer birer işler. ANAHTARLAR'ın ardından verilen başka komutlarınız varsa, Redis KEYS komutunu işleyene kadar bunlar işlenmez. redis.io sitesinde, desteklediği her işlem için zaman karmaşıklığıyla ilgili ayrıntılar bulunur. Her işlemin karmaşıklığını görmek için her komutu seçin.
• Anahtar boyutları - Küçük anahtar/değerler mi yoksa büyük anahtar/değerler mi kullanmalıyım? Senaryoya bağlıdır. Senaryonuz daha büyük anahtarlar gerektiriyorsa ConnectionTimeout değerini ayarlayabilir, ardından değerleri yeniden deneyebilir ve yeniden deneme mantığınızı ayarlayabilirsiniz. Redis sunucusu açısından bakıldığında, küçük değerler daha iyi performans sağlar.
• Bu önemli noktalar Redis'te daha büyük değerleri depolayabileceğiniz anlamına gelmez; aşağıdaki noktaları bilmeniz gerekir. Gecikme süreleri daha yüksek olacaktır. Daha büyük ve daha küçük bir veri kümeniz varsa, birden çok ConnectionMultiplexer örneği kullanabilirsiniz. StackExchange.Redis yapılandırma seçenekleri ne yapar? bölümünde açıklandığı gibi her birini farklı bir zaman aşımı kümesiyle yapılandırın ve değerleri yeniden deneyin.

• Önbelleğinizin sistem durumunu izleyebilmeniz için önbellek tanılamayı etkinleştirin. Azure portalında ölçümleri görüntüleyebilir ve ayrıca istediğiniz araçları kullanarak bunları indirebilir ve gözden geçirebilirsiniz.
• Redis sunucunuzu yüklemek için redis-benchmark.exe kullanabilirsiniz.
• Yük testi istemcisinin ve Redis için Azure Cache aynı bölgede olduğundan emin olun.
• redis-cli.exe kullanın ve BİlGİ komutunu kullanarak önbelleği izleyin.
• Yükünüz yüksek bellek parçalanmalarına neden oluyorsa ölçeği daha büyük bir önbellek boyutuna artırmanız gerekir.
• Redis araçlarını indirme yönergeleri için Redis komutlarını nasıl çalıştırabilirim? bölümüne bakın.

redis-benchmark.exe kullanımına bazı örnekler aşağıda verilmiştir. Doğru results.cache-development-faq.yml için bu komutları önbelleğinizle aynı bölgedeki bir VM'den çalıştırın

• 1k yükü kullanarak İşlem Hattına Alınmış SET isteklerini test edin

  redis-benchmark.exe -h **yourcache**.redis.cache.windows.net -a **yourAccesskey** -t SET -n 1000000 -d 1024 -P 50

• 1k yükü kullanarak İşlem Hattına Alınmış GET isteklerini test edin.

redis-benchmark.exe -h **yourcache**.redis.cache.windows.net -a **yourAccesskey** -t GET -n 1000000 -d 1024 -P 50

CLR ThreadPool iki tür iş parçacığına sahiptir: "Çalışan" ve "G/Ç Tamamlama Bağlantı Noktası" (IOCP) iş parçacıkları.

• Çalışan iş parçacıkları, veya ThreadPool.QueueUserWorkItem(…) yöntemlerini işleme Task.Run(…)gibi işlemler için kullanılır. Bu iş parçacıkları, arka plan iş parçacığında iş yapılması gerektiğinde CLR'deki çeşitli bileşenler tarafından da kullanılır.
• IOCP iş parçacıkları, ağdan okuma gibi zaman uyumsuz GÇ gerçekleştiğinde kullanılır.

İş parçacığı havuzu, her iş parçacığı türü için "Minimum" ayarına ulaşana kadar isteğe bağlı (azaltma olmadan) yeni çalışan iş parçacıkları veya G/Ç tamamlama iş parçacıkları sağlar. Varsayılan olarak, en az iş parçacığı sayısı bir sistemdeki işlemci sayısına ayarlanır.

Mevcut (meşgul) iş parçacıklarının sayısı "en düşük" iş parçacığı sayısına ulaştığında, ThreadPool her 500 milisaniyede bir iş parçacığına yeni iş parçacıkları ekleme hızını kısıtlar. Genellikle, sisteminiz bir IOCP iş parçacığına ihtiyaç duyan bir iş patlamasıyla karşılaşıyorsa, bunu hızlı bir şekilde işler. Bununla birlikte, seri artış yapılandırılan "Minimum" ayarından daha fazlaysa ThreadPool iki olasılıktan birini beklediğinden, işin bir bölümünü işlemede biraz gecikme olur:

• Mevcut bir iş parçacığı, işi işlemek için serbest hale gelir.
• Mevcut iş parçacığı 500 ms boyunca boş olmaz ve yeni bir iş parçacığı oluşturulur.

Temel olarak, Meşgul iş parçacıklarının sayısı Min iş parçacıklarından büyük olduğunda, ağ trafiği uygulama tarafından işlenmeden önce büyük olasılıkla 500 ms gecikme ödersiniz. Ayrıca mevcut bir iş parçacığı 15 saniyeden uzun süre boşta kaldığında temizlenir ve bu büyüme ve küçülme döngüsü tekrarlanabilir.

StackExchange.Redis'ten (derleme 1.0.450 veya üzeri) örnek bir hata iletisine bakarsak, artık ThreadPool istatistiklerini yazdırdığını görürüz. Aşağıdaki IOCP ve WORKER ayrıntılarına bakın.

System.TimeoutException: Timeout performing GET MyKey, inst: 2, mgr: Inactive,
queue: 6, qu: 0, qs: 6, qc: 0, wr: 0, wq: 0, in: 0, ar: 0,
IOCP: (Busy=6,Free=994,Min=4,Max=1000),
WORKER: (Busy=3,Free=997,Min=4,Max=1000)

Örnekte gösterildiği gibi, IOCP iş parçacığı için altı meşgul iş parçacığı olduğunu ve sistemin dört minimum iş parçacığına izin verecek şekilde yapılandırıldığını görürsünüz. Bu durumda, istemci büyük olasılıkla 6 > 4 olduğundan iki 500 ms gecikme görmüş olabilir.

Öneri

Bu bilgiler göz önüne alındığında, müşterilerin IOCP ve WORKER iş parçacıkları için en düşük yapılandırma değerini varsayılan değerden daha büyük bir değere ayarlamalarını kesinlikle öneririz. Bir uygulama için doğru değerin başka bir uygulama için büyük olasılıkla çok yüksek veya düşük olması nedeniyle bu değerin ne olması gerektiği konusunda herkese uygun bir kılavuz sağlayamıyoruz. Bu ayar karmaşık uygulamaların diğer bölümlerinin performansını da etkileyebilir, bu nedenle her müşterinin bu ayarı kendi ihtiyaçlarına göre ayarlaması gerekir. İyi bir başlangıç noktası 200 veya 300'dür, ardından gerektiğinde test edin ve ince ayar yapın.

Bu ayar nasıl yapılandırılır:

• 'de global.asax.csThreadPool.SetMinThreads (...) yöntemini kullanarak bu ayarı program aracılığıyla değiştirmenizi öneririz. Örneğin:

  private readonly int minThreads = 200;
  void Application_Start(object sender, EventArgs e)
  {
      // Code that runs on application startup
      AreaRegistration.RegisterAllAreas();
      RouteConfig.RegisterRoutes(RouteTable.Routes);
      BundleConfig.RegisterBundles(BundleTable.Bundles);
      ThreadPool.SetMinThreads(minThreads, minThreads);
  }
  

  Not

  Bu yöntem tarafından belirtilen değer, AppDomain'in tamamını etkileyen genel bir ayardır. Örneğin, 4 çekirdekli bir makineniz varsa ve çalışma zamanında minWorkerThreads ve minIoThreads değerlerini CPU başına 50 olarak ayarlamak istiyorsanız ThreadPool.SetMinThreads(200, 200) kullanın.

• minIoThreads veya minWorkerThreads yapılandırma ayarını içindeki Machine.configyapılandırma öğesi altında <processModel> kullanarak en düşük iş parçacıkları ayarını belirtmek de mümkündür. Machine.config genellikle konumunda %SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\bulunur. Sistem genelinde bir ayar olduğundan minimum iş parçacığı sayısını bu şekilde ayarlamak önerilmez.

  Not

  Bu yapılandırma öğesinde belirtilen değer çekirdek başına bir ayardır. Örneğin, 4 çekirdekli bir makineniz varsa ve minIoThreads ayarınızın çalışma zamanında 200 olmasını istiyorsanız kullanabilirsiniz<processModel minIoThreads="50"/>.

Sunucu GC'nin etkinleştirilmesi, StackExchange.Redis kullanırken istemciyi iyileştirebilir ve daha iyi performans ve aktarım hızı sağlayabilir. Sunucu GC hakkında daha fazla bilgi ve nasıl etkinleştirileceği hakkında daha fazla bilgi için aşağıdaki makalelere bakın:

• Sunucu GC'yi etkinleştirmek için
• Atık Toplamanın Temelleri
• Atık Toplama ve Performans

Her fiyatlandırma katmanının istemci bağlantıları, bellek ve bant genişliği için farklı sınırları vardır. Önbelleğin her boyutu en fazla bir sayıda bağlantıya izin verirken, Redis'e yapılan her bağlantının kendisiyle ilişkili ek yükü vardır. TLS/SSL şifrelemesi nedeniyle CPU ve bellek kullanımı bu tür bir ek yüke örnek olabilir. Belirli bir önbellek boyutu için en yüksek bağlantı sınırı, hafifçe yüklenen bir önbellek olduğunu varsayar. Bağlantı yükünden gelen yük ve istemci işlemlerinden gelen yük sistemin kapasitesini aşıyorsa, geçerli önbellek boyutu için bağlantı sınırını aşmamış olsanız bile önbellek kapasite sorunlarıyla karşılaşabilir.

Her katman için farklı bağlantı sınırları hakkında daha fazla bilgi için bkz. fiyatlandırma Redis için Azure Cache. Bağlantılar ve diğer varsayılan yapılandırmalar hakkında daha fazla bilgi için bkz . Varsayılan Redis sunucusu yapılandırması.

Sonraki adımlar

Diğer Redis için Azure Cache SSS hakkında bilgi edinin.