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 Oturum Durumu Sağlayıcısı duyuru blog gönderi ASP.NET sindeki yönergeleri izleyerek araçları TLS bağlantı noktasına güvenli bir şekilde bağlamak için gibi stunnel bir yardımcı program 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. Bir bağlantının nasıl yönetileceğini gösteren bir örnek için Redisconnection ile önbelleğe bağlanma bölümündeki sınıfa bakınRedisConnection.
• Redis daha küçük değerlerle en iyi şekilde çalıştığından, 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 olduğunda 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 sitesi, desteklediği her işlem için zaman karmaşıklığıyla ilgili ayrıntılar içerir. 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 ve test senaryoları için kullanılır.
• Redis'in bellek içi bir veri deposu olduğunu unutmayın. Daha fazla bilgi için bkz. veri kaybının oluşabileceği senaryoları fark edebilmeniz için Redis için Azure Cache veri kaybı sorunlarını giderme.
• Sisteminizi, düzeltme eki uygulama ve yük devretmenin neden olduğu bağlantı sinyallerini işleyebilecek şekilde geliştirin.

Performansı test etme

• Kendi performans testlerinizi yazmadan önce olası aktarım hızı hissini 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 aracılığıyla 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ğinle aynı bölgede olmalıdır.
• daha iyi donanıma sahip olduklarından ve en iyi sonuçları vermesi gerektiğinden istemciniz için Dv2 VM Serisi kullanmanızı öneririz.
• Seçtiğiniz istemci VM'sinin 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. Anahtarların 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. KEYS komutundan sonra verilen başka komutlarınız varsa, Redis KEYS komutunu işleyene kadar bunlar işlenmez. redis.io sitesi, desteklediği her işlem için zaman karmaşıklığıyla ilgili ayrıntılar içerir. 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 depolayamazsınız 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. Önceki StackExchange.Redis yapılandırma seçenekleri ne yapar bölümünde açıklandığı gibi her birini farklı bir zaman aşımı ve yeniden deneme değerleri kümesiyle yapılandırın.

• Ö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.
• BİlGİ komutunu kullanarak redis-cli.exe kullanın ve ö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 sonuçlar için önbelleğinizle aynı bölgedeki bir VM'den bu komutları çalıştırın.cache-development-faq.yml

• 1k yük kullanarak İşlem Hattıyla Sınanan SET isteklerini test etme

  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ş olması 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 "En Düşük" 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ığı ekleme hızını kısıtlar. Genellikle, sisteminiz 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 "En Düşük" ayarından daha fazlaysa ThreadPool iki olasılıktan birini beklediği için bazı işlerin işlenmesinde biraz gecikme yaşanıyor:

• 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 fazla 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 büzülme döngüsü tekrarlanabilir.

StackExchange.Redis'ten (derleme 1.0.450 veya üzeri) gelen ö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ğer büyük olasılıkla başka bir uygulama için çok yüksek veya düşük olduğundan, bu değerin ne olması gerektiği konusunda herkese uygun tek bir kılavuz sunamıyoruz. Bu ayar karmaşık uygulamaların diğer bölümlerinin performansını da etkileyebilir, bu nedenle her müşterinin bu ayarı belirli ihtiyaçlarına göre ayarlaması gerekir. İyi bir başlangıç noktası 200 veya 300'dür, ardından gerektiğinde test edip ince ayar yapın.

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

• içinde ThreadPool.SetMinThreads (...) yöntemini global.asax.cskullanarak 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ı sırasında cpu başına minWorkerThreads ve minIoThreads değerini 50 olarak ayarlamak istiyorsanız ThreadPool.SetMinThreads(200, 200) kullanın.

• minimum iş parçacıkları ayarını, içindeki yapılandırma öğesinin Machine.configaltındaki <processModel>minIoThreads veya minWorkerThreads yapılandırma ayarını kullanarak da belirtebilirsiniz. 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'sini etkinleştirmek, StackExchange.Redis kullanırken istemciyi iyileştirebilir ve daha iyi performans ve aktarım hızı sağlayabilir. Sunucu GC'si ve nasıl etkinleştirileceği hakkında daha fazla bilgi için aşağıdaki makalelere bakın:

• Sunucu GC'sini etkinleştirmek için
• Atık Toplamanın Temelleri
• Çöp 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. Her önbellek boyutu bir miktar bağlantıya izin verirken, Redis'e yapılan her bağlantının 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üklenmiş bir önbellek olduğunu varsayar. Bağlantı yükünden gelen yük ve istemci işlemlerinden gelen yük sistem kapasitesini aşarsa, 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 hakkında SSS hakkında bilgi edinin.