Dayanıklı İşlevler'de performans ve ölçeklendirme

Dayanıklı İşlevler uygulamanızın performans ve ölçeklendirme davranışını ayarlamak için bu makaleyi kullanın. Ayarlayabileceğiniz ana kaldıraçları kapsar:

Important

Python veya PowerShell kullanıyorsanız eşzamanlılık ayarlarını yapılandırmadan önce Dil çalışma zamanıyla ilgili dikkat edilmesi gerekenler konusunu okuyun. Yanlış yapılandırılmış eşzamanlılık, etkinliklerin tek bir çalışanda durmasına neden olabilir.

Çalışan ölçeklendirmesi

Görev hub'ı kavramının ana avantajlarından biri, iş öğelerini işleyen çalışan sayısının skalanabilir olmasıdır. Uygulamalar, işleri daha hızlı işlemek için çalışan ekler (yatay büyüme) ve yeterli iş olmadığında çalışanları kaldırır (yatay küçülme). Görev hub'ı boşta olduğunda sıfıra bile ölçeklendirin. Sıfıra ölçeklendirdiğinizde, hiçbir çalışan çalışmaz. Yalnızca ölçek denetleyicisi ve depolama etkin kalır.

Aşağıdaki diyagramda bu kavram gösterilmektedir:

Bir görev hub'ı için Dayanıklı İşlevler çalışanlarının ölçeği genişletmesini, ölçeği küçültmesini ve sıfıra ölçeklendirmesini gösteren diyagram.

Otomatik ölçeklendirme

Tüketim ve Elastik Premium planlarında Dayanıklı İşlevler, Azure İşlevleri ölçek denetleyicisi aracılığıyla otomatik ölçeklendirmeyi destekler. Ölçek denetleyicisi, iletilerin ve görevlerin işlenmeden önce ne kadar süre bekleyeceğini izler. Bu gecikme sürelerine bağlı olarak çalışanları ekler veya kaldırır.

Not

Dayanıklı İşlevler 2.0'dan başlayarak, Elastik Premium planındaki sanal ağ korumalı hizmet uç noktalarındaki işlev uygulamalarını çalıştıracak şekilde yapılandırabilirsiniz. Bu yapılandırmada, Dayanıklı İşlevler tetikleyiciler ölçek denetleyicisi yerine ölçek isteklerini başlatmaktadır. Daha fazla bilgi için bkz . Çalışma zamanı ölçeği izleme.

Premium planda otomatik ölçeklendirme, çalışan sayısını (ve işletim maliyetini) kabaca uygulamanın yüküyle orantılı tutar.

Eşzamanlılık sınırlayıcıları

Tek bir çalışan örneği aynı anda birden çok iş öğesi yürütebilir. Bu, paralelliği artırır ve çalışan kaynaklarını daha verimli bir şekilde kullanır. Ancak bir çalışan aynı anda çok fazla iş öğesi işlerse CPU, ağ bağlantıları ve bellek gibi kaynakları tüketebilir.

Belirli bir çalışanın aşırı yüklenmesini önlemek için, örnek başına eşzamanlılığı sınırlamanız gerekebilir. Her çalışanda aynı anda çalışan işlevlerin sayısını sınırlamak, o çalışanın kaynak sınırlarına isabet etmekten kaçınmaya yardımcı olur.

Not

Eşzamanlılık kısıtlamaları yalnızca yerel olarak uygulanır ve çalışan başına işlemenin sınırlandırılmasını sağlar. Bu nedenle toplam sistem aktarım hızını sınırlamaz.

Tip

Bazı durumlarda çalışan başına eşzamanlılığı azaltma, sistemin toplam aktarım hızını artırabilir . Bu durum, her çalışan daha az iş aldığında ortaya çıkar ve ölçek denetleyicisinin kuyruklara ayak uydurmak için daha fazla çalışan eklemesine neden olur ve bu da toplam aktarım hızını artırır.

Eşzamanlılık kısıtlamalarını yapılandırın

host.json dosyasında etkinlik, düzenleyici ve varlık işlevi eşzamanlılık sınırlarını yapılandırın. Etkinlik işlevleri için durableTask/maxConcurrentActivityFunctions, orchestrator ve varlık işlevleri için durableTask/maxConcurrentOrchestratorFunctions kullanın. Bu ayarlar, bir çalışanın belleğe yükleyebileceği düzenleyici, varlık ve etkinlik işlevlerini sınırlar.

Not

Düzenleme ve varlıklar yalnızca olayları veya işlemleri işlerken veya örnek önbelleğe alma etkinleştirildiğinde belleğe yüklenir. Mantıklarını çalıştırdıktan ve bekledikten sonra (örneğin, C# dilinde await veya JavaScript ve Python'da yield), bellekten kaldırılabilirler. Yüklenmemiş orchestrasyonlar ve bileşenler kısıtlama maxConcurrentOrchestratorFunctions kapsamına girmez. Milyonlarca örnek "Çalışıyor" durumunda olsa bile, yalnızca bellekteki örnekler kısıtlama sınırına kadar sayılır. Bir etkinliğin bitmesini bekleyen bir orkestrasyon da sınırlamaya dahil edilmez.

{
  "extensions": {
    "durableTask": {
      "maxConcurrentActivityFunctions": 10,
      "maxConcurrentOrchestratorFunctions": 10
    }
  }
}

Dil çalışma zamanıyla ilgili dikkat edilmesi gerekenler

Seçtiğiniz dil çalışma zamanı, işlevlerinize katı eşzamanlılık kısıtlamaları uygulayabilir. Örneğin, Python veya PowerShell'de yazılmış Dayanıklı İşlevler uygulamalar tek bir VM'de aynı anda yalnızca bir işlev çalıştırabilir. Bu durum, bunu dikkate alamıyorsanız performans sorunlarına neden olabilir. Bir düzenleyici 10 etkinliği desteklerse ancak dil çalışma zamanı yalnızca bir işlevin çalışmasına izin veriyorsa, 10 etkinlik işlevinden dokuzu çalışma şansı beklerken takılır. Ayrıca, Dayanıklı İşlevler çalışma zamanı bunları belleğe zaten yüklediğinden, bu bekleme etkinlikleri diğer çalışanlara yük dengelenemez. Bu durum özellikle etkinlik işlevleri uzun süre çalıştığında sorunludur.

Dil çalışma zamanınız eşzamanlılığı kısıtlarsa, Dayanıklı İşlevler eşzamanlılık ayarlarını eşleşecek şekilde güncelleştirin. Bu, Dayanıklı İşlevler çalışma zamanının dil çalışma zamanının izin verdiğinden daha fazla işlevi eşzamanlı olarak çalıştırmasını engeller ve bekleyen etkinliklerin diğer VM'lere yük dengelemesini sağlar. Örneğin, bir Python uygulaması eşzamanlılığı dört işlevle kısıtlarsa (örneğin, tek dil çalışan işleminde 4 iş parçacığı veya 4 dil çalışanı işleminde 1 iş parçacığı), hem maxConcurrentOrchestratorFunctions hem de maxConcurrentActivityFunctions'yi 4 olarak yapılandırın.

Python performans önerileri için bkz. Azure İşlevleri Python uygulamalarının aktarım hızı performansını sağlama. Bu teknikler Dayanıklı İşlevler performansını ve ölçeklenebilirliğini önemli ölçüde iyileştirebilir.

Örnek önbelleğe alma

Bir düzenleme iş öğesini işlemek için çalışan iki şey yapar:

  1. Orkestrasyon geçmişini alın.
  2. Geçmişi kullanarak orchestrator kodunu tekrar yürüt.

Aynı çalışan aynı düzenleme için birden çok iş öğesini işlerse, depolama sağlayıcısı ilk adımı ortadan kaldırmak için çalışanın belleğindeki geçmişi önbelleğe alabilir. Ayrıca, yürütme sırasındaki orkestratörü önbelleğe alarak sonraki iş öğeleri için geçmişi yeniden oynatmayı önleyebilir.

Düzenlemelerinizin çok sayıda bölümü olduğunda ve yüksek yeniden yürütme yükü gördüğünüzde önbelleğe almayı etkinleştirin. Önbelleğe alma genellikle G/Ç'yi temel depolama hizmetine düşürür ve aktarım hızını ve gecikme süresini artırır, ancak çalışan belleği kullanımını da artırır.

Tip

Önbelleğe alma, çalışma zamanının geçmişi yeniden yürütme sıklıklarını azaltabilir, ancak yeniden yürütmeyi ortadan kaldıramaz. Geliştirme sırasında önbelleğe alma devre dışı bırakılmış şekilde düzenleyicileri test edin. Zorlamalı yeniden yürütme , orchestrator işlev kodu kısıtlamalarının ihlallerini algılamanıza yardımcı olur.

Not

Dayanıklı Görev Zamanlayıcı, önbelleğe almayı dahili olarak yönetir. Aşağıdaki yapılandırma ayrıntıları yalnızca BYO depolama sağlayıcıları için geçerlidir.

Depolama sağlayıcısı tarafından önbelleğe alma

Aşağıdaki tabloda, sağlayıcılar arasında örnek önbelleğe alma desteği karşılaştırılır ve her birinin nasıl yapılandırılacağı özetlenir.

Azure Depolama sağlayıcısı Netherite depolama sağlayıcısı MSSQL depolama sağlayıcısı
Örnek önbelleğe alma Destekleniyor
(.NET işlem içi çalışanı yalnızca)		 Destekleniyor Desteklenmiyor
Varsayılan ayar Disabled Enabled Yok
Mekanizma Genişletilmiş Oturumlar Örnek Önbelleği Yok

Genişletilmiş oturumlar (Azure Depolama sağlayıcısı), belirli bir süre boşta kalana kadar yürütme sürecindeki orkestratörleri bellekte tutar. extendedSessionsEnabled ve extendedSessionIdleTimeoutInSeconds, host.json dosyanızda bu davranışı etkinleştirin ve ayarlayın.

{
  "extensions": {
    "durableTask": {
      "extendedSessionsEnabled": true,
      "extendedSessionIdleTimeoutInSeconds": 30
    }
  }
}

Not

Genişletilmiş oturumlar yalnızca .NET işlem içi çalışanda desteklenir. Ayrıntılar için Azure Depolama sağlayıcısı belgelerindeki Extended sessions bölümüne bakın.

Örnek önbelleği (Netherite depolama sağlayıcısı), örnek durumunu ve geçmişini çalışanın belleğinde tutar ve toplam bellek kullanımını izler. Önbellek sınırı aşarsa InstanceCacheSizeMB , en son kullanılan örnek verilerini kaldırır. CacheOrchestrationCursors, true olarak ayarlarsanız önbellek, yürütme ortası düzenleyicilerini de depolar.

Not

Örnek önbellekleri tüm dil SDK'larıyla çalışır, ancak CacheOrchestrationCursors seçeneği yalnızca .NET işlem içi çalışanı için kullanılabilir. Ayrıntılar için Netherite depolama sağlayıcısı belgelerindeki Örnek önbelleği bölümüne bakın.

Bölüm sayısı

Bazı depolama sağlayıcıları bölümleme özelliğini destekler ve ayarlamanızı sağlar partitionCount.

Bölümleme ile, çalışanlar bireysel iş öğeleri için rekabet etmek zorunda kalmazlar. Bölümleme, iş öğelerini bölümlere ayırır partitionCount ve çalışma zamanı çalışanlara bölümler atar. Bu yaklaşım, toplam depolama erişimi sayısını azaltır. Ayrıca örnek önbelleğe almayı etkinleştirir ve benzini oluşturarak yerelliği geliştirir: aynı çalışan, aynı örnek için tüm iş öğelerini işler.

Not

Dayanıklı Görev Zamanlayıcı, bölümleme işlemini dahili olarak yönetir. Aşağıdaki yapılandırma ayrıntıları yalnızca BYO depolama sağlayıcıları için geçerlidir.

Çoğu uygulama için varsayılan bölüm sayısı yeterlidir. tr-TR: Bölüm sayısı, bölümlenmiş bir kuyruktan orkestrasyon mesajlarını işleyebilecek çalışan sayısını sınırladığı için, orkestrasyonlar için varsayılan çalışan sayısının ötesine ölçeklendirmeyi bekliyorsanız, bunu artırın.

Aşağıdaki tabloda, her depolama sağlayıcısı bölümlerinin hangi kuyruklarda olduğu ve için partitionCountizin verilen aralık ve varsayılan değerler gösterilmektedir.

Azure Depolama sağlayıcısı Netherite depolama sağlayıcısı MSSQL depolama sağlayıcısı
Genel mesajlar Bölümlenmiş Bölümlenmiş Bölümlenmedi
Etkinlik iletileri Bölümlenmedi Bölümlenmiş Bölümlenmedi
Varsayılan partitionCount 4 12 Yok
Maksimum partitionCount 16 32 Yok
Dokümantasyon Bkz Orchestrator ölçeklendirme Bkz . Bölüm sayısıyla ilgili dikkat edilmesi gerekenler Yok

Warning

Görev hub'ı oluşturduktan sonra bölüm sayısını değiştiremezsiniz. Görev hub'ı örneği için beklenen ölçek genişletme gereksinimlerini karşılayacak kadar yüksek ayarlayın.

Bölüm sayısını yapılandırma

partitionCount dosyasını host.json içinde belirtin. Aşağıdaki host.json kod parçacığı, durableTask/storageProvider/partitionCount'yi 3 olarak ayarlar.

{
  "extensions": {
    "durableTask": {
      "storageProvider": {
        "partitionCount": 3
      }
    }
  }
}

İşlev yürütme davranışı

Bu bölümde performansı etkileyen yürütme ayrıntıları ele alınıyor: her işlev türünün ne tür bir işi işlemesi gerektiği, zaman aşımlarının nasıl çalıştığı ve varlık işlemlerinin nasıl toplu işlendiği.

İşlev türüne göre iş yerleşimi

Orchestrator işlevleri , mantıklarını yeniden oynattığı için, birden çok kez çalıştırırlar. Bu nedenle, orchestrator işlev iş parçacıklarının CPU yoğun görevleri gerçekleştirmemesi, G/Ç işlemi yapmaması veya blokaj oluşturmaması önemlidir. I/O, engelleme veya birden çok iş parçacığı gerektirebilen işleri, etkinlik fonksiyonlarına taşıyın.

Etkinlik işlevleri , kuyrukla tetiklenen normal işlevler gibi davranır. Onlar, G/Ç, yoğun işlem gerektiren CPU işlemleri ve birden çok iş parçacığını destekler. Etkinlik tetikleyicileri durum bilgisi taşımadıkları için birçok VM'ye ölçeklenebilir.

Varlık işlevleri de tek bir iş parçacığında çalışır ve işlemleri birer birer işler. Varlık işlevleri, çalıştırdıkları kodun türü üzerinde hiçbir kısıtlamaya sahip değildir.

İşlev zaman aşımları

Etkinlik, düzenleyici ve varlık işlevleri, diğer Azure işlevleriyle aynı işlev zaman aşımlarına tabidir. Dayanıklı İşlevler, bir işlev zaman aşımını kodunuzda işlenmeyen bir özel durum gibi ele alır.

Örneğin, bir faaliyet zaman aşımına uğradığında, Dayanıklı İşlevler yürütmenin başarısız olduğunu kaydeder ve orkestratöre bildirir. Orchestrator, zaman aşımını tıpkı diğer özel durumlar gibi işler: Çağrı yeniden denemeye izin veriyorsa, çalışma zamanı bu işlemi tekrarlar; aksi takdirde, bir özel durum işleyici çalıştırılır.

Varlık işlemlerinin toplu yürütülmesi

Performansı artırmak ve maliyeti azaltmak için tek bir iş öğesi bir grup varlık işlemi yürütebilir. Tüketim planında, her toplu işlem tek bir işlev yürütmesi olarak faturalandırılır.

Varsayılan olarak, maksimum toplu iş boyutu Tüketim planında 50, diğer planlarda 5.000'dir. ayrıca host.json dosyasındaki en büyük toplu iş boyutunu yapılandırabilirsiniz. En büyük toplu iş boyutu 1 ise toplu işlem etkin bir şekilde devre dışı bırakılır.

Not

Tek tek varlık işlemlerinin yürütülmesi uzun sürüyorsa, özellikle Tüketim planında işlev zaman aşımları riskini azaltmak için maksimum toplu iş boyutunu sınırlamak yararlı olabilir.

Performans hedefleri

Dayanıklı İşlevler içeren bir üretim uygulaması planlarken performans gereksinimlerini erken göz önünde bulundurun. Bu temel kullanım senaryoları şunları planlamanıza yardımcı olur:

  • Sıralı etkinlik yürütme: Bu senaryo, sırayla bir dizi etkinlik işlevi çalıştıran bir orchestrator işlevini açıklar. İşlev zincirleme örneğine en yakın şekilde benzer.
  • Paralel etkinlik yürütme: Bu senaryoda, Fan-out, fan-in desenini kullanarak birçok etkinlik işlevini paralel olarak yürüten bir orchestrator işlevi açıklanır.
  • Paralel yanıt işleme: Bu senaryo Fan-out, fan-in deseninin ikinci yarısıdır. Fan-in performansına odaklanır. Fan-out'un aksine, fan-in tek bir orchestrator işlev örneğinde çalışır, bu nedenle tek bir VM üzerinde çalışır.
  • Dış olay işleme: Bu senaryo, tek tek dış olayları bekleyen tek bir orchestrator işlev örneğini temsil eder.
  • Varlık işlemi işleme: Bu senaryo, tek bir Counter varlığının sabit bir işlem akışını ne kadar hızlı işleyebileceğini test eder.

Bu senaryolar için aktarım hızı numaraları depolama sağlayıcısı belgelerinde yer alır. Özellikle:

Tip

Fan-out'un aksine, fan-in işlemleri tek bir VM ile sınırlıdır. Uygulamanız fan-out, fan-in desenini kullanıyorsa ve fan-in performansından endişeleniyorsanız, etkinlik işlevi fan-out'u birden çok alt düzenleme arasında dağıtmayı göz önünde bulundurun.

Sonraki Adımlar

Azure Depolama sağlayıcısı

  • Last updated on