Azure Yönetilen Redis yönetimi hakkında SSS

  • Şunlara uygulanır: ✅ Azure Managed Redis

Bu makalede, Azure Yönetilen Redis'i yönetme hakkında sık sorulan soruların yanıtları sağlanır.

Redis’e bağlanmak için TLS/SSL olmayan bağlantı noktasını ne zaman etkinleştirmeliyim?

TLS'nin kullanılması, neredeyse tüm Redis kullanım durumlarında en iyi uygulama olarak önerilir. Geriye dönük uyumluluk amacıyla TLS olmadan bağlanma seçeneği dahil edilir.

Bazı üretim en iyi yöntemleri nelerdir?

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. 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

  • Redis'in bellek içi veri deposu olduğunu unutmayın. Daha fazla bilgi için bkz . Azure Yönetilen Redis'te veri kaybı sorunlarını giderme, böylece veri kaybının gerçekleşebileceğ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 testleri

Yaygın Redis komutlarını kullanırken dikkat edilmesi gerekenlerden bazıları nelerdir?

  • 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. Her Redis parçası tek iş parçacıklı bir parçadır 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üksektir. 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ı ve yeniden deneme değerleri kümesiyle yapılandırın.

Önbelleğimin performansını nasıl kıyaslayabilirim ve test ederim?

ThreadPool büyümesi hakkında önemli ayrıntılar

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 Task.Run(…) yöntemlerini işleme ThreadPool.QueueUserWorkItem(…)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ığı 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 fazla olduğunda, uygulama ağ trafiğini işlemeden ö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. Makalenin devamında 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, 6 > 4 olduğundan iki 500 ms gecikme görür.

Uyarı

IoCP veya WORKER iş parçacıklarının büyümesi kısıtlanırsa StackExchange.Redis zaman aşımlarına neden olabilir.

Tavsiye

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ı öneririz. Bir uygulama için doğru değer başka bir uygulama için çok yüksek veya düşük olabileceğinden, bu değerle ilgili her boyuta uyan kılavuz sağlayamıyoruz. Bu ayar, karmaşık uygulamaların diğer bölümlerinin performansını da etkileyebilir. 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:

.NET Framework ve .NET Core uygulamalarında ThreadPool.SetMinThreads (...) yöntemini kullanarak bu ayarı program aracılığıyla değiştirmenizi öneririz.

Örneğin, NET Framework'te Global.asax.cs bunu yönteminde Application_Start ayarlarsınız:

```csharp
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);
}
```

.NET Core kullanıyorsanız, çağrısından Program.cshemen önce içinde WebApplication.CreateBuilder()ayarlarsınız:

```csharp
const int minThreads = 200
              
ThreadPool.SetMinThreads(minThreads, minThreads);

var builder = WebApplication.CreateBuilder(args);
// rest of application setup
```

Uyarı

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

içindeki yapılandırma öğesinin minIoThreadsaltındaki minWorkerThreads veya <processModel> kullanarak Machine.config 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.

Minimum iş parçacığı sayısının bu şekilde ayarlanması, sistem genelinde bir ayar olduğundan önerilmez. Bu şekilde ayarlarsanız, uygulama havuzunu yeniden başlatmanız gerekir.

Uyarı

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

StackExchange.Redis kullanırken istemcide daha fazla aktarım hızı elde etmek için sunucu GC'yi etkinleştirme

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:

Bağlantılarla ilgili performansla ilgili dikkat edilmesi gerekenler

farklı SKU'ların istemci bağlantıları, bellek ve bant genişliği için farklı sınırları olabilir. Ö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 ve istemci işlemlerinden gelen yük sistem kapasitesini aşıyorsa, geçerli önbellek boyutu için bağlantı sınırını aşmasanı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 . Azure Yönetilen Redis fiyatlandırması.

İlgili içerik

  • Last updated on