Dayanıklı İşlevler'de pe ve ölçek (Azure İşlevleri)

Performansı ve ölçeklenebilirliği iyileştirmek için Dayanıklı İşlevler benzersiz ölçeklendirme özelliklerini anlamak önemlidir. Bu makalede, çalışanların yüke göre nasıl ölçeklendirilebileceklerini ve çeşitli parametreleri nasıl ayarlayabileceklerini açıklayacağız.

Çalışan ölçeklendirmesi

Görev hub'ı kavramının temel avantajlarından biri, görev hub'ı iş öğelerini işleyen çalışan sayısının sürekli olarak ayarlanabilmesidir. Özellikle uygulamalar, işin daha hızlı işlenmesi gerekiyorsa daha fazla çalışan ekleyebilir (ölçeği genişletebilir) ve çalışanları meşgul etmek için yeterli iş yoksa çalışanları kaldırabilir (ölçeği daraltabilir). Görev hub'ı tamamen boştaysa sıfıra ölçeklendirmek bile mümkündür. Sıfıra ölçeklendirildiğinde, hiç işçi yoktur; yalnızca ölçek denetleyicisi ve depolamanın etkin kalması gerekir.

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

Otomatik ölçeklendirme

Tüketim ve Elastik Premium planlarında çalışan tüm Azure İşlevleri gibi, 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 beklemesi gerekenleri izler. Bu gecikme sürelerine bağlı olarak, çalışan ekleyip eklememeye veya kaldırmaya karar verebilir.

Not

Dayanıklı İşlevler 2.0'dan başlayarak, işlev uygulamaları Elastik Premium planındaki sanal ağ korumalı hizmet uç noktaları içinde çalışacak şekilde yapılandırılabilir. Bu yapılandırmada, Dayanıklı İşlevler tetikleyicileri Ölçek Denetleyicisi yerine ölçek istekleri başlatı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 dolayısıyla işletim maliyetini) kabaca uygulamanın yaşadığı yükle orantılı tutmaya yardımcı olabilir.

CPU kullanımı

Orchestrator işlevleri , yürütmenin birçok yeniden yürütmede belirleyici olmasını sağlamak için tek bir iş parçacığında yürütülür. Bu tek iş parçacıklı yürütme nedeniyle, orchestrator işlev iş parçacıklarının cpu yoğunluklu görevler gerçekleştirmemesi, G/Ç gerçekleştirmemesi veya herhangi bir nedenle engellememesi önemlidir. G/Ç, engelleme veya birden çok iş parçacığı gerektirebilecek tüm çalışmalar etkinlik işlevlerine taşınmalıdır.

Etkinlik işlevleri , kuyrukla tetiklenen normal işlevlerle aynı davranışlara sahiptir. Güvenli bir şekilde G/Ç yapabilir, YOĞUN CPU kullanan işlemler yürütebilir ve birden çok iş parçacığı kullanabilirler. Etkinlik tetikleyicileri durum bilgisi olmadığından, sınırsız sayıda VM'ye serbestçe ölçeklendirilebilir.

Varlık işlevleri de tek bir iş parçacığında yürütülür ve işlemler birer birer işlenir. Ancak varlık işlevlerinin yürütülebilecek kod türüyle ilgili herhangi bir kısıtlaması yoktur.

İşlev zaman aşımları

Etkinlik, düzenleyici ve varlık işlevleri, tüm Azure İşlevleri aynı işlev zaman aşımlarına tabidir. Genel bir kural olarak, Dayanıklı İşlevler işlev zaman aşımlarını uygulama kodu tarafından işlenmeyen özel durumlarla aynı şekilde ele alır.

Örneğin, bir etkinlik zaman aşımına uğradıysa işlev yürütmesi hata olarak kaydedilir ve düzenleyiciye bildirilir ve zaman aşımını diğer özel durumlar gibi işler: çağrı tarafından belirtilirse yeniden denemeler gerçekleşir veya bir özel durum işleyicisi yürütülebilir.

Varlık işlemi toplu işlemi

Performansı geliştirmek ve maliyeti azaltmak için tek bir iş öğesi varlık işlemlerinin tamamını yürütebilir. Tüketim planları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 planları için 50 ve diğer tüm planlar için 5000'dir. En büyük toplu iş boyutu host.json dosyasında da yapılandırılabilir. 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 planlarında işlev zaman aşımları riskini azaltmak için maksimum toplu iş boyutunu sınırlamak yararlı olabilir.

Örnek önbelleğe alma

Genel olarak, bir düzenleme iş öğesini işlemek için bir çalışanın her ikisine de sahip olması gerekir

1. Düzenleme geçmişini getirin.
2. Geçmişi kullanarak orchestrator kodunu yeniden yürütebilirsiniz.

Aynı çalışan aynı düzenleme için birden çok iş öğesini işliyorsa, depolama sağlayıcısı çalışanın belleğindeki geçmişi önbelleğe alarak bu işlemi iyileştirebilir ve bu da ilk adımı ortadan kaldırır. Ayrıca, ikinci adımı, geçmiş gösterimini de ortadan kaldıran orta yürütme düzenleyiciyi önbelleğe alabilir.

Önbelleğe alma işleminin tipik etkisi, temel alınan depolama hizmetine karşı G/Ç'nin azaltılması ve genel olarak geliştirilmiş aktarım hızı ve gecikme süresidir. Öte yandan önbelleğe alma, çalışan üzerindeki bellek tüketimini artırır.

Örnek önbelleğe alma şu anda Azure Depolama sağlayıcısı ve Netherite depolama sağlayıcısı tarafından desteklenmektedir. Aşağıdaki tabloda bir karşılaştırma sağlanır.

	Azure Depolama sağlayıcısı	Netherite depolama sağlayıcısı	MSSQL depolama sağlayıcısı
Örnek önbelleğe alma	Desteklenir (yalnızca.NET işlem içi çalışanı)	Desteklenir	Desteklenmez
Varsayılan ayar	Devre Dışı	Etkin	yok
Mekanizma	Genişletilmiş Oturumlar	Örnek Önbelleği	yok
Belgeler	Bkz. Genişletilmiş oturumlar	Bkz. Örnek önbelleği	yok

İpucu

Önbelleğe alma, geçmişlerin yeniden oynatılması sıklığını azaltabilir, ancak yeniden yürütmeyi tamamen ortadan kaldıramaz. Düzenleyici geliştirirken, önbelleğe almayı devre dışı bırakabilen bir yapılandırmada bunları test etmenizi kesinlikle öneririz. Bu zorlamalı yeniden yürütme davranışı, geliştirme zamanında orchestrator işlev kodu kısıtlamaları ihlallerini algılamak için yararlı olabilir.

Önbelleğe alma mekanizmalarının karşılaştırması

Sağlayıcılar önbelleğe alma uygulamak için farklı mekanizmalar kullanır ve önbelleğe alma davranışını yapılandırmak için farklı parametreler sunar.

• Azure Depolama sağlayıcısı tarafından kullanılan genişletilmiş oturumlar, yürütme ortası düzenleyicilerini bir süre boşta kalana kadar bellekte tutar. Bu mekanizmayı denetlemek için ve parametreleridir extendedSessionsEnabled extendedSessionIdleTimeoutInSeconds. Daha fazla ayrıntı için Azure Depolama sağlayıcısı belgelerinin Genişletilmiş oturumlar bölümüne bakın.

Not

Genişletilmiş oturumlar yalnızca .NET işlem içi çalışanında desteklenir.

• Netherite depolama sağlayıcısı tarafından kullanılan Örnek önbelleği, geçmişleri de dahil olmak üzere tüm örneklerin durumunu çalışanın belleğinde tutarken kullanılan toplam belleği de izler. Önbellek boyutu tarafından InstanceCacheSizeMByapılandırılan sınırı aşarsa, en son kullanılan örnek verileri çıkarılır. true olarak ayarlanırsa CacheOrchestrationCursors önbellek, örnek durumuyla birlikte yürütme ortası düzenleyicilerini de depolar. Daha fazla ayrıntı için Netherite depolama sağlayıcısı belgelerinin Örnek önbelleği bölümüne bakın.

Not

Örnek önbellekleri tüm dil SDK'ları için çalışır, ancak CacheOrchestrationCursors bu seçenek yalnızca .NET işlem içi çalışanı için kullanılabilir.

Eşzamanlılık azaltmaları

Tek bir çalışan örneği aynı anda birden çok iş öğesi yürütebilir. Bu, paralelliği artırmaya ve işçileri daha verimli bir şekilde kullanmasına yardımcı olur. Ancak, bir çalışan aynı anda çok fazla iş öğesi işlemeye çalışırsa, CPU yükü, ağ bağlantısı sayısı veya kullanılabilir bellek gibi kullanılabilir kaynaklarını tüketebilir.

Tek bir çalışanın aşırı işlem yapmadığından emin olmak için örnek başına eşzamanlılığı kısıtlamak gerekebilir. Her çalışanda eşzamanlı olarak çalışan işlevlerin sayısını sınırlayarak bu çalışandaki kaynak sınırlarının tükenmesini önleyebiliriz.

Not

Eşzamanlılık azaltmaları, çalışan başına işlenmekte olan işlemleri sınırlamak için yalnızca yerel olarak uygulanır. Bu nedenle, bu azaltmalar sistemin toplam aktarım hızını sınırlamaz.

İpucu

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.

Kısıtlama yapılandırması

Etkinlik, düzenleyici ve varlık işlevi eşzamanlılık sınırları host.json dosyasında yapılandırılabilir. İlgili ayarlar durableTask/maxConcurrentActivityFunctions etkinlik işlevlerine ve durableTask/maxConcurrentOrchestratorFunctions hem orchestrator hem de varlık işlevlerine yöneliktir. Bu ayarlar, tek bir çalışanda belleğe yüklenen en fazla düzenleyici, varlık veya etkinlik işlevi sayısını denetler.

Not

Düzenleme ve varlıklar yalnızca olayları veya işlemleri etkin bir şekilde işlerken veya örnek önbelleğe alma etkinleştirildiğinde belleğe yüklenir. Kendi mantığını yürüttükten ve orchestrator işlev kodunda bir await (C#) veya yield (JavaScript, Python) deyimine ulaşıldığında) bekledikten sonra bellekten kaldırılabilir. Bellekten kaldırılan düzenleme ve varlıklar kısıtlamaya maxConcurrentOrchestratorFunctions doğru sayılmaz. Milyonlarca düzenleme veya varlık "Çalışıyor" durumunda olsa bile, yalnızca etkin belleğe yüklendiklerinde azaltma sınırına doğru sayılırlar. Bir etkinlik işlevini benzer şekilde zamanlayan bir düzenleme, düzenlemenin etkinliğin yürütülmesini beklemesi durumunda kısıtlamaya doğru sayılmaz.

İşlevler 2.0

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

İşlevler 1.x

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

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

Seçtiğiniz dil çalışma zamanı katı eşzamanlılık kısıtlamaları veya işlevlerinizi uygulayabilir. Örneğin, Python veya PowerShell ile yazılmış Dayanıklı İşlev uygulamaları tek bir VM'de tek bir işlevin aynı anda çalıştırılmasını destekleyemeyebilir. Bu, dikkatli bir şekilde dikkate alınmazsa önemli performans sorunlarına neden olabilir. Örneğin, bir düzenleyici 10 etkinliğe hayran kalıyorsa ancak dil çalışma zamanı eşzamanlılığı yalnızca bir işlevle kısıtlarsa, 10 etkinlik işlevinden 9'u çalışma şansı beklerken takılır. Ayrıca, Dayanıklı İşlevler çalışma zamanı bunları belleğe zaten yüklemiş olacağı için bu 9 takılan etkinlik diğer çalışanlara yük dengelemesi yapamayacaktır. Etkinlik işlevleri uzun süre çalışıyorsa bu durum özellikle sorunlu hale gelir.

Kullandığınız dil çalışma zamanı eşzamanlılık kısıtlaması getirirse, Dayanıklı İşlevler eşzamanlılık ayarlarını dil çalışma zamanınızın eşzamanlılık ayarlarıyla eşleşecek şekilde güncelleştirmeniz gerekir. Bu, Dayanıklı İşlevler çalışma zamanının dil çalışma zamanı tarafından izin verilenden daha fazla işlevi eşzamanlı olarak çalıştırmayı denememesini sağlar ve bekleyen etkinliklerin diğer VM'lere yük dengelemesine olanak tanır. Örneğin, eşzamanlılığı 4 işlevle kısıtlayan bir Python uygulamanız varsa (tek dil çalışan işleminde yalnızca 4 iş parçacığıyla veya 4 dil çalışanı işleminde 1 iş parçacığıyla yapılandırılmış olabilir) hem hem de maxConcurrentOrchestratorFunctions maxConcurrentActivityFunctions 4 ile yapılandırmanız gerekir.

Python hakkında daha fazla bilgi ve performans önerileri için bkz. Azure İşlevleri Python uygulamalarının aktarım hızı performansını geliştirme. Bu Python geliştirici başvuru belgelerinde bahsedilen teknikler, Dayanıklı İşlevler performans ve ölçeklenebilirlik üzerinde önemli bir etkiye sahip olabilir.

Bölüm sayısı

Bazı depolama sağlayıcıları bir bölümleme mekanizması kullanır ve parametre partitionCount belirtmeye izin verir.

Bölümleme kullanılırken, çalışanlar tek tek iş öğeleri için doğrudan rekabete girmez. Bunun yerine, iş öğeleri önce bölümler halinde partitionCount gruplandırılır. Bu bölümler daha sonra çalışanlara atanır. Bu bölümlenmiş yük dağıtımı yaklaşımı, gereken toplam depolama erişimi sayısını azaltmaya yardımcı olabilir. Ayrıca, örnek önbelleğe almayı etkinleştirebilir ve benzini oluşturduğundan yerelliği iyileştirebilir: aynı örneğe ilişkin tüm iş öğeleri aynı çalışan tarafından işlenir.

Not

Bölümleme sınırlarının ölçeği genişletilir çünkü çoğu partitionCount çalışan bölümlenmiş bir kuyruktan iş öğelerini işleyebilir.

Aşağıdaki tabloda, her depolama sağlayıcısı için hangi kuyrukların bölümlendiği ve parametre için partitionCount izin 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ı
Örnek iletileri	Partitioned	Partitioned	Bölümlenmedi
Etkinlik iletileri	Bölümlenmedi	Partitioned	Bölümlenmedi
Temerrüt partitionCount	4	12	yok
Maksimum partitionCount	16	32	yok
Belgeler	Bkz. Orchestrator ölçeği genişletme	Bkz. Bölüm sayısıyla ilgili dikkat edilmesi gerekenler	yok

Uyarı

Görev hub'ı oluşturulduktan sonra bölüm sayısı artık değiştirilemez. Bu nedenle, görev hub'ı örneğinin gelecekteki ölçek genişletme gereksinimlerini karşılamak için yeterince büyük bir değere ayarlanması önerilir.

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

partitionCount parametresi host.json dosyasında belirtilebilir. Aşağıdaki örnek host.json kod parçacığı özelliğini (veya durableTask/partitionCount Dayanıklı İşlevler 1.x'te) olarak 3ayarlardurableTask/storageProvider/partitionCount.

Dayanıklı İşlevler 2.x

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

Dayanıklı İşlevler 1.x

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

Çağırma gecikme sürelerini en aza indirmek için dikkat edilmesi gerekenler

Normal koşullarda, çağırma istekleri (etkinliklere, düzenleyicilere, varlıklara vb.) oldukça hızlı bir şekilde işlenmelidir. Ancak, herhangi bir çağrı isteğinin maksimum gecikme süresi garanti edilemez çünkü bu, App Service Planınızın ölçek davranışı türü, eşzamanlılık ayarlarınız ve uygulamanızın kapsam boyutu gibi faktörlere bağlıdır. Bu nedenle, uygulamanızın kuyruk gecikme sürelerini ölçmek ve iyileştirmek için stres testine yatırım yapmanızı öneririz.

Performans hedefleri

Bir üretim uygulaması için Dayanıklı İşlevler kullanmayı planlarken, planlama sürecinin başlarında performans gereksinimlerini göz önünde bulundurmak önemlidir. Bazı temel kullanım senaryoları şunlardır:

• Sıralı etkinlik yürütme: Bu senaryoda, bir dizi etkinlik işlevini birbiri ardına çalıştıran bir orchestrator işlevi açıklanır. İş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 işleminin tek bir orchestrator işlev örneği tarafından yapıldığını ve bu nedenle yalnızca tek bir VM'de çalışabileceğini unutmayın.
• 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.

Depolama sağlayıcılarının ilgili belgelerinde bu senaryolar için aktarım hızı numaraları sağlıyoruz. Özellikle:

• Azure Depolama sağlayıcısı için bkz . Performans Hedefleri.
• Netherite depolama sağlayıcısı için bkz . Temel Senaryolar.
• MSSQL depolama sağlayıcısı için bkz . Orchestration Aktarım Hızı Karşılaştırmaları.

İpucu

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şlevinin fanını birden çok alt düzenlemeye bölmeyi göz önünde bulundurun.

Sonraki adımlar

Azure Depolama sağlayıcısı hakkında bilgi edinin