Önbellek yönetimi hakkında SSS

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

Önemli

Redis için Azure Cache, tüm SKU'lar için kullanımdan kaldırma zaman çizelgesini duyurdu. Mevcut Redis için Azure Cache örneklerinizi en kısa sürede Azure Yönetilen Redis'e taşımanızı öneririz.

Kullanımdan kaldırma hakkında daha fazla bilgi için:

• Azure Cache for Redis Emekliliği: Bilmeniz Gerekenler ve Nasıl Hazırlanmalısınız?
• Azure Cache for Redis Hizmetinin Kullanımdan Çekilmesi Hakkında SSS

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

• Redis sunucunuzun yük testini yapmak için kullanın redis-benchmark.exe . Kendi performans testlerinizi yazmadan önce olası aktarım hızı hakkında bir fikir edinmek için kullanın redis-benchmark.exe .
• komutunu kullanarak redis-cli önbelleği izlemek için kullanınINFO. Redis araçlarını indirme yönergeleri için bkz: Redis komutlarını nasıl çalıştırabilirim?
• Önbellek örneğinizde Aktarım Katmanı Güvenliği/Güvenli Yuva Katmanı (TLS/SSL) kullanıyorsanız, parametreyi --tls Redis araçları komutlarınıza ekleyin veya TLS/SSL'yi etkinleştirmek için benzer stunnel bir ara sunucu kullanın.
• Redis-benchmark Varsayılan olarak bağlantı noktasını 6379 kullanır. Önbelleğiniz -p SSL/TLS bağlantı noktasını veya Enterprise katmanı bağlantı 6380 noktasını 10000kullanıyorsa bu ayarı geçersiz kılmak için parametresini kullanın.
• Gerekirse, yük testini çalıştırmadan önce TLS olmayan bağlantı noktasını Azure portal aracılığıyla etkinleştirebilirsiniz .
• Test için kullandığınız istemci sanal makinesinin (VM) Redis için Azure Cache örneğinizle aynı bölgede olduğundan emin olun.
• İstemci VM'nizin en az test ettiğiniz önbellek kadar bilgi işlem ve bant genişliği özelliğine sahip olduğundan emin olun. En iyi sonuçları elde etmek için istemcileriniz için D serisi ve E serisi VM'leri kullanın.
• Windows kullanıyorsanız, istemci makinede Sanal Alma Tarafı Ölçeklendirme'yi (VRSS) etkinleştirin. Daha fazla bilgi için bkz: Windows Server 2012 R2'de Sanal Alma Tarafı Ölçeklendirme.
• Önbelleğinizin sistem durumunu izleyebilmek için önbellek tanılamalarını etkinleştirin. Ölçümleri Azure portal görüntüleyebilir ve ayrıca tercih ettiğiniz araçları kullanarak ölçümlerinizi indirebilir ve gözden geçirebilirsiniz .
• Yükünüz yüksek bellek parçalanmasına neden oluyorsa, ölçeği daha büyük bir önbellek boyutuna yükseltin.

Aşağıdaki örneklerde nasıl kullanılacağı redis-benchmark.exegösterilmektedir. Doğru sonuçlar için bu komutları önbelleğinizle aynı bölgedeki bir VM'den çalıştırın.

İlk olarak, 1k yükü kullanarak ardışık düzende SET istekleri test edin:

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

Testi çalıştırdıktan SET sonra, 1k yükü kullanarak ardışık düzen GET isteklerini çalıştırın:

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

StackExchange.Redis kullanırken istemcide daha fazla aktarım hızı elde etmek için sunucu GC'sini nasıl etkinleştirebilirim?

Sunucu çöp toplamayı (GC) etkinleştirmek, istemciyi en iyi duruma getirebilir ve StackExchange.Redis kullandığınızda 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:

• <gcServer> öğesi
• Çöp toplamanın temelleri
• Çöp toplama ve performans

Redis'e bağlanmak için TLS/SSL olmayan bağlantı noktasını etkinleştirmeli miyim?

Redis sunucusu Aktarım Katmanı Güvenliği'ni (TLS) yerel olarak desteklemez, ancak Redis için Azure Cache TLS'yi destekler. Redis için Azure Cache'e TLS'yi destekleyen StackExchange.Redis gibi bir istemciyle bağlanırsanız TLS'yi kullanın.

Not

TLS olmayan bağlantı noktası, yeni Azure Redis örnekleri için varsayılan olarak devre dışıdır. İstemciniz TLS'yi desteklemiyorsa Erişim bağlantı noktaları'ndaki yönergeleri izleyerek TLS olmayan bağlantı noktasını etkinleştirin.

Önbellek TLS kullanıyorsa, gibi --tlsRedis araçları seçeneğini kullanarak TLS'yi redis-cli etkinleştirmeniz gerekir. Ayrıca, stunnel blog gönderisindeki yönergeleri izleyerek araçları TLS bağlantı noktasına güvenli bir şekilde bağlamak gibi bir yardımcı program da kullanabilirsiniz.

Redis araçlarını indirme yönergeleri için bkz: Redis komutlarını nasıl çalıştırabilirim?

Yaygın Redis komutlarını kullanırken dikkat edilmesi gereken bazı noktalar 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. Redis, komutları tek tek işleyen tek iş parçacıklı bir sunucudur. Komutu verirseniz KEYS Redis komutu işlemeyi tamamlayana kadar sonraki komutları işlemez KEYS .

  redis.io sitesi, desteklediği her işlem için zaman karmaşıklığı ayrıntılarına sahiptir. Her işlemin karmaşıklığını görmek için her komutu seçin.

• Hangi boyutta anahtarların kullanılacağı senaryoya bağlıdır. Senaryonuz daha büyük anahtarlar gerektiriyorsa, , ardından yeniden deneme değerlerini ayarlayabilir ConnectionTimeoutve yeniden deneme mantığınızı ayarlayabilirsiniz. Redis sunucusu açısından bakıldığında, daha küçük anahtar değerleri daha iyi performans sağlar.

• Bu önemli noktalar Redis'te daha büyük değerler depolayamayacağınız anlamına gelmez, ancak gecikme süreleri daha yüksektir. Diğerinden daha büyük bir veri kümeniz varsa, her biri farklı bir zaman aşımı ve yeniden deneme değerleri kümesiyle yapılandırılmış birden çok ConnectionMultiplexer örnek kullanabilirsiniz. Daha fazla bilgi için bkz: StackExchange.Redis yapılandırma seçenekleri ne işe yarar?

Bağlantılar için performansla ilgili dikkat edilmesi gereken bazı noktalar nelerdir?

Her Redis için Azure Cache 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 en fazla sayıda bağlantıya izin verse de, Redis'e yapılan her bağlantı ilişkili ek yük içerir. Bu tür ek yüklere bir örnek, TLS/SSL şifrelemesi nedeniyle CPU ve bellek kullanımıdır.

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ı ek 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şmasanız bile önbellek kapasite sorunlarıyla karşılaşabilir.

Her katmanın bağlantı sınırları hakkında daha fazla bilgi için bkz. 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ı.

Bazı üretim en iyi yöntemleri nelerdir?

• Üretim sistemleri için Standart veya Premium katmanını kullanın. Temel Katman, veri çoğaltması ve hizmet düzeyi sözleşmesi (SLA) olmayan tek düğümlü bir sistemdir. Ayrıca, Üretim için en az bir C1 önbelleği kullanın. C0 önbellekleri genellikle basit geliştirme/test senaryoları için kullanılır.
• Redis'in bellek içi bir veri deposu olduğunu ve bazı senaryolarda veri kaybı olabileceğini unutmayın. Daha fazla bilgi için bkz: Redis için Azure Cache'de veri kaybı sorunlarını giderme.
• Sisteminizi, düzeltme eki uygulama ve yük devretmenin neden olduğu bağlantı hatalarını işleyebilecek şekilde geliştirin.
• Hem CPU hem de ağ için daha iyi donanıma sahip olduklarından daha iyi ağ gecikme süresi ve aktarım hızı için Premium katman Azure Redis örneklerini kullanın.

StackExchange.Redis en iyi yöntemleri

• false olarak ayarlayın AbortConnect , ardından otomatik olarak yeniden bağlanmasına ConnectionMultiplexer 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. Örneğin, Redis için ideal değer boyutu aralığı nedir? bölümünde 100 kb büyük olarak kabul edilir. Daha fazla bilgi için, bkz: Daha fazla anahtar ve daha küçük değerler düşünme.
• Zaman aşımlarını önlemek için ThreadPool ayarlarınızı yapılandırın.
• Varsayılan değer olan en az 5 saniyeyi connectTimeout kullanın. Bu aralık, StackExchange.Redis'e bir ağ blip'i varsa bağlantıyı yeniden kurmak için yeterli zaman verir.
• Çalıştırdığınız farklı işlemlerle ilişkili performans maliyetlerinin farkında olun. Örneğin, KEYS komut bir O(n) işlemidir ve bundan kaçınılmalıdır. redis.io sitesi, desteklediği her işlemin zaman karmaşıklığı hakkında ayrıntılara sahiptir. Her işlemin karmaşıklığını görmek için her komutu seçin.

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

Ortak Dil Çalışma Zamanı (CLR) ThreadPool'un iki tür iş parçacığı vardır: Çalışan ve G/Ç Tamamlama Bağlantı Noktası (IOCP).

• WORKERİş parçacıkları, veya Task.Run(…) yöntemlerini işlemek ThreadPool.QueueUserWorkItem(…)gibi şeyler için kullanılır. CLR'deki çeşitli bileşenler, işin bir arka plan iş parçacığı üzerinde gerçekleşmesi gerektiğinde de bu iş parçacıklarını kullanır.
• IOCP iş parçacıkları, ağdan okurken olduğu gibi zaman uyumsuz G/Ç için kullanılır.

İş parçacığı havuzu, her iş parçacığı türü için ayara ulaşana kadar herhangi bir azaltma olmadan isteğe bağlı olarak yeni çalışan iş parçacıkları veya G/Ç tamamlama iş parçacıkları minimum 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ı iş parçacığı sayısına ulaştığında minimum , ThreadPool 500 milisaniyede bir iş parçacığına yeni iş parçacığı ekleme hızını kısıtlar.

Tipik olarak, sisteminiz bir iş parçacığı gerektiren bir iş patlaması alırsa, hızlı bir IOCP şekilde çalışan işler. Ancak, seri aktarım yapılandırılan minimum ayardan daha fazlaysa, ThreadPool iki olasılıktan birini beklerken işin bir kısmının işlenmesinde biraz gecikme olur:

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

Temel olarak, iş parçacığı sayısı iş parçacığı sayısından BusyMin büyük olduğunda, uygulama ağ trafiğini işlemeden önce 500 ms'lik bir gecikme yaşarsınız. Ayrıca, 15 saniyeden daha uzun süre boşta kalan mevcut bir iplik temizlenir ve bu büyüme ve büzülme döngüsü tekrarlanabilir.

StackExchange.Redis derleme 1.0.450 veya sonraki sürümlerden gelen hata iletileri, aşağıdaki örnekte gösterildiği gibi ThreadPool istatistiklerini yazdırır.

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)

Örnek, iş parçacığı için altı meşgul iş parçacığı olduğunu ve sistemin en az dört iş parçacığına IOCP izin verecek şekilde yapılandırıldığını gösterir. Bu durumda, istemcinin iki adet 500 ms'lik gecikme görmesi muhtemeldir, çünkü 6 > 4.

Not

StackExchange.Redis, iş parçacıklarından birinin IOCP veya WORKER iş parçacıklarının büyümesi kısıtlanırsa zaman aşımlarına çarpabilir.

ve IOCP iş parçacıkları için WORKER en düşük yapılandırma değerini varsayılan değerden daha büyük bir değere ayarlamak en iyisidir. Bir uygulama için doğru değer başka bir uygulama için büyük olasılıkla çok yüksek veya düşük olduğundan, bu değerle ilgili herkese uyan tek bir kılavuz yoktur. Bu ayar, karmaşık uygulamaların diğer bölümlerinin performansını da etkileyebilir. Bu ayarı özel ihtiyaçlarınıza göre ayarlamanız gerekir. İyi bir başlangıç yeri veya 200'dir300. Ardından test edin ve gerektiği gibi ince ayar yapın.

En düşük iş parçacığı ayarını yapılandırın

ThreadPool.SetMinThreads (...) yöntemini kullanarak bu ayarı program aracılığıyla değiştirebilirsiniz.

Örneğin, NET Framework'te bu değeri yöntemde Application_Start olarak ayarlarsınız:

    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ıdan hemen önce Program.cs içindeki değeri şu şekilde WebApplication.CreateBuilder()ayarlarsınız:

    const int minThreads = 200
                  
    ThreadPool.SetMinThreads(minThreads, minThreads);
    
    var builder = WebApplication.CreateBuilder(args);
    // rest of application setup

Not

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

Ayrıca, içindeki yapılandırma öğesinin minIoThreads altındaki minWorkerThreads veya yapılandırma ayarını kullanarak en <processModel> düşük iş parçacığı ayarını belirtmek de mümkündür Machine.config. Machine.config genellikle %SystemRoot%\Microsoft.NET\Framework\<versionNumber>\CONFIG\ konumunda bulunur.

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

Not

Bu yöntem tarafından 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">.

İlgili içerik

• Diğer Redis için Azure Cache SSS'lerine bakın.

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

Önemli

Redis için Azure Cache, tüm SKU'lar için kullanımdan kaldırma zaman çizelgesini duyurdu. Mevcut Redis için Azure Cache örneklerinizi en kısa sürede Azure Yönetilen Redis'e taşımanızı öneririz.

Kullanımdan kaldırma hakkında daha fazla bilgi için:

• Azure Cache for Redis Emekliliği: Bilmeniz Gerekenler ve Nasıl Hazırlanmalısınız?
• Azure Cache for Redis Hizmetinin Kullanımdan Çekilmesi Hakkında SSS

• Redis sunucunuzun yük testini yapmak için kullanın redis-benchmark.exe . Kendi performans testlerinizi yazmadan önce olası aktarım hızı hakkında bir fikir edinmek için kullanın redis-benchmark.exe .
• komutunu kullanarak redis-cli önbelleği izlemek için kullanınINFO. Redis araçlarını indirme yönergeleri için bkz: Redis komutlarını nasıl çalıştırabilirim?
• Önbellek örneğinizde Aktarım Katmanı Güvenliği/Güvenli Yuva Katmanı (TLS/SSL) kullanıyorsanız, parametreyi --tls Redis araçları komutlarınıza ekleyin veya TLS/SSL'yi etkinleştirmek için benzer stunnel bir ara sunucu kullanın.
• Redis-benchmark Varsayılan olarak bağlantı noktasını 6379 kullanır. Önbelleğiniz -p SSL/TLS bağlantı noktasını veya Enterprise katmanı bağlantı 6380 noktasını 10000kullanıyorsa bu ayarı geçersiz kılmak için parametresini kullanın.
• Gerekirse, yük testini çalıştırmadan önce TLS olmayan bağlantı noktasını Azure portal aracılığıyla etkinleştirebilirsiniz .
• Test için kullandığınız istemci sanal makinesinin (VM) Redis için Azure Cache örneğinizle aynı bölgede olduğundan emin olun.
• İstemci VM'nizin en az test ettiğiniz önbellek kadar bilgi işlem ve bant genişliği özelliğine sahip olduğundan emin olun. En iyi sonuçları elde etmek için istemcileriniz için D serisi ve E serisi VM'leri kullanın.
• Windows kullanıyorsanız, istemci makinede Sanal Alma Tarafı Ölçeklendirme'yi (VRSS) etkinleştirin. Daha fazla bilgi için bkz: Windows Server 2012 R2'de Sanal Alma Tarafı Ölçeklendirme.
• Önbelleğinizin sistem durumunu izleyebilmek için önbellek tanılamalarını etkinleştirin. Ölçümleri Azure portal görüntüleyebilir ve ayrıca tercih ettiğiniz araçları kullanarak ölçümlerinizi indirebilir ve gözden geçirebilirsiniz .
• Yükünüz yüksek bellek parçalanmasına neden oluyorsa, ölçeği daha büyük bir önbellek boyutuna yükseltin.

Aşağıdaki örneklerde nasıl kullanılacağı redis-benchmark.exegösterilmektedir. Doğru sonuçlar için bu komutları önbelleğinizle aynı bölgedeki bir VM'den çalıştırın.

İlk olarak, 1k yükü kullanarak ardışık düzende SET istekleri test edin:

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

Testi çalıştırdıktan SET sonra, 1k yükü kullanarak ardışık düzen GET isteklerini çalıştırın:

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

Sunucu çöp toplamayı (GC) etkinleştirmek, istemciyi en iyi duruma getirebilir ve StackExchange.Redis kullandığınızda 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:

• <gcServer> öğesi
• Çöp toplamanın temelleri
• Çöp toplama ve performans

Redis sunucusu Aktarım Katmanı Güvenliği'ni (TLS) yerel olarak desteklemez, ancak Redis için Azure Cache TLS'yi destekler. Redis için Azure Cache'e TLS'yi destekleyen StackExchange.Redis gibi bir istemciyle bağlanırsanız TLS'yi kullanın.

Not

TLS olmayan bağlantı noktası, yeni Azure Redis örnekleri için varsayılan olarak devre dışıdır. İstemciniz TLS'yi desteklemiyorsa Erişim bağlantı noktaları'ndaki yönergeleri izleyerek TLS olmayan bağlantı noktasını etkinleştirin.

Önbellek TLS kullanıyorsa, gibi --tlsRedis araçları seçeneğini kullanarak TLS'yi redis-cli etkinleştirmeniz gerekir. Ayrıca, stunnel blog gönderisindeki yönergeleri izleyerek araçları TLS bağlantı noktasına güvenli bir şekilde bağlamak gibi bir yardımcı program da kullanabilirsiniz.

Redis araçlarını indirme yönergeleri için bkz: Redis komutlarını nasıl çalıştırabilirim?

• 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, komutları tek tek işleyen tek iş parçacıklı bir sunucudur. Komutu verirseniz KEYS Redis komutu işlemeyi tamamlayana kadar sonraki komutları işlemez KEYS .

  redis.io sitesi, desteklediği her işlem için zaman karmaşıklığı ayrıntılarına sahiptir. Her işlemin karmaşıklığını görmek için her komutu seçin.

• Hangi boyutta anahtarların kullanılacağı senaryoya bağlıdır. Senaryonuz daha büyük anahtarlar gerektiriyorsa, , ardından yeniden deneme değerlerini ayarlayabilir ConnectionTimeoutve yeniden deneme mantığınızı ayarlayabilirsiniz. Redis sunucusu açısından bakıldığında, daha küçük anahtar değerleri daha iyi performans sağlar.

• Bu önemli noktalar Redis'te daha büyük değerler depolayamayacağınız anlamına gelmez, ancak gecikme süreleri daha yüksektir. Diğerinden daha büyük bir veri kümeniz varsa, her biri farklı bir zaman aşımı ve yeniden deneme değerleri kümesiyle yapılandırılmış birden çok ConnectionMultiplexer örnek kullanabilirsiniz. Daha fazla bilgi için bkz: StackExchange.Redis yapılandırma seçenekleri ne işe yarar?

Her Redis için Azure Cache 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 en fazla sayıda bağlantıya izin verse de, Redis'e yapılan her bağlantı ilişkili ek yük içerir. Bu tür ek yüklere bir örnek, TLS/SSL şifrelemesi nedeniyle CPU ve bellek kullanımıdır.

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ı ek 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şmasanız bile önbellek kapasite sorunlarıyla karşılaşabilir.

Her katmanın bağlantı sınırları hakkında daha fazla bilgi için bkz. 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ı.

• Üretim sistemleri için Standart veya Premium katmanını kullanın. Temel Katman, veri çoğaltması ve hizmet düzeyi sözleşmesi (SLA) olmayan tek düğümlü bir sistemdir. Ayrıca, Üretim için en az bir C1 önbelleği kullanın. C0 önbellekleri genellikle basit geliştirme/test senaryoları için kullanılır.
• Redis'in bellek içi bir veri deposu olduğunu ve bazı senaryolarda veri kaybı olabileceğini unutmayın. Daha fazla bilgi için bkz: Redis için Azure Cache'de veri kaybı sorunlarını giderme.
• Sisteminizi, düzeltme eki uygulama ve yük devretmenin neden olduğu bağlantı hatalarını işleyebilecek şekilde geliştirin.
• Hem CPU hem de ağ için daha iyi donanıma sahip olduklarından daha iyi ağ gecikme süresi ve aktarım hızı için Premium katman Azure Redis örneklerini kullanın.

StackExchange.Redis en iyi yöntemleri

• false olarak ayarlayın AbortConnect , ardından otomatik olarak yeniden bağlanmasına ConnectionMultiplexer 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. Örneğin, Redis için ideal değer boyutu aralığı nedir? bölümünde 100 kb büyük olarak kabul edilir. Daha fazla bilgi için, bkz: Daha fazla anahtar ve daha küçük değerler düşünme.
• Zaman aşımlarını önlemek için ThreadPool ayarlarınızı yapılandırın.
• Varsayılan değer olan en az 5 saniyeyi connectTimeout kullanın. Bu aralık, StackExchange.Redis'e bir ağ blip'i varsa bağlantıyı yeniden kurmak için yeterli zaman verir.
• Çalıştırdığınız farklı işlemlerle ilişkili performans maliyetlerinin farkında olun. Örneğin, KEYS komut bir O(n) işlemidir ve bundan kaçınılmalıdır. redis.io sitesi, desteklediği her işlemin zaman karmaşıklığı hakkında ayrıntılara sahiptir. Her işlemin karmaşıklığını görmek için her komutu seçin.

Ortak Dil Çalışma Zamanı (CLR) ThreadPool'un iki tür iş parçacığı vardır: Çalışan ve G/Ç Tamamlama Bağlantı Noktası (IOCP).

• WORKERİş parçacıkları, veya Task.Run(…) yöntemlerini işlemek ThreadPool.QueueUserWorkItem(…)gibi şeyler için kullanılır. CLR'deki çeşitli bileşenler, işin bir arka plan iş parçacığı üzerinde gerçekleşmesi gerektiğinde de bu iş parçacıklarını kullanır.
• IOCP iş parçacıkları, ağdan okurken olduğu gibi zaman uyumsuz G/Ç için kullanılır.

İş parçacığı havuzu, her iş parçacığı türü için ayara ulaşana kadar herhangi bir azaltma olmadan isteğe bağlı olarak yeni çalışan iş parçacıkları veya G/Ç tamamlama iş parçacıkları minimum 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ı iş parçacığı sayısına ulaştığında minimum , ThreadPool 500 milisaniyede bir iş parçacığına yeni iş parçacığı ekleme hızını kısıtlar.

Tipik olarak, sisteminiz bir iş parçacığı gerektiren bir iş patlaması alırsa, hızlı bir IOCP şekilde çalışan işler. Ancak, seri aktarım yapılandırılan minimum ayardan daha fazlaysa, ThreadPool iki olasılıktan birini beklerken işin bir kısmının işlenmesinde biraz gecikme olur:

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

Temel olarak, iş parçacığı sayısı iş parçacığı sayısından BusyMin büyük olduğunda, uygulama ağ trafiğini işlemeden önce 500 ms'lik bir gecikme yaşarsınız. Ayrıca, 15 saniyeden daha uzun süre boşta kalan mevcut bir iplik temizlenir ve bu büyüme ve büzülme döngüsü tekrarlanabilir.

StackExchange.Redis derleme 1.0.450 veya sonraki sürümlerden gelen hata iletileri, aşağıdaki örnekte gösterildiği gibi ThreadPool istatistiklerini yazdırır.

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)

Örnek, iş parçacığı için altı meşgul iş parçacığı olduğunu ve sistemin en az dört iş parçacığına IOCP izin verecek şekilde yapılandırıldığını gösterir. Bu durumda, istemcinin iki adet 500 ms'lik gecikme görmesi muhtemeldir, çünkü 6 > 4.

Not

StackExchange.Redis, iş parçacıklarından birinin IOCP veya WORKER iş parçacıklarının büyümesi kısıtlanırsa zaman aşımlarına çarpabilir.

ve IOCP iş parçacıkları için WORKER en düşük yapılandırma değerini varsayılan değerden daha büyük bir değere ayarlamak en iyisidir. Bir uygulama için doğru değer başka bir uygulama için büyük olasılıkla çok yüksek veya düşük olduğundan, bu değerle ilgili herkese uyan tek bir kılavuz yoktur. Bu ayar, karmaşık uygulamaların diğer bölümlerinin performansını da etkileyebilir. Bu ayarı özel ihtiyaçlarınıza göre ayarlamanız gerekir. İyi bir başlangıç yeri veya 200'dir300. Ardından test edin ve gerektiği gibi ince ayar yapın.

En düşük iş parçacığı ayarını yapılandırın

ThreadPool.SetMinThreads (...) yöntemini kullanarak bu ayarı program aracılığıyla değiştirebilirsiniz.

Örneğin, NET Framework'te bu değeri yöntemde Application_Start olarak ayarlarsınız:

    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ıdan hemen önce Program.cs içindeki değeri şu şekilde WebApplication.CreateBuilder()ayarlarsınız:

    const int minThreads = 200
                  
    ThreadPool.SetMinThreads(minThreads, minThreads);
    
    var builder = WebApplication.CreateBuilder(args);
    // rest of application setup

Not

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

Ayrıca, içindeki yapılandırma öğesinin minIoThreads altındaki minWorkerThreads veya yapılandırma ayarını kullanarak en <processModel> düşük iş parçacığı ayarını belirtmek de mümkündür Machine.config. Machine.config genellikle %SystemRoot%\Microsoft.NET\Framework\<versionNumber>\CONFIG\ konumunda bulunur.

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

Not

Bu yöntem tarafından 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">.

İlgili içerik

• Diğer Redis için Azure Cache SSS'lerine bakın.