Azure Depolama sağlayıcısı (Azure İşlevleri)

Bu belge, performans ve ölçeklenebilirlik özelliklerine odaklanarak Dayanıklı İşlevler Azure Depolama sağlayıcısının özelliklerini açıklar. Azure Depolama sağlayıcısı varsayılan sağlayıcıdır. Örnek durumlarını ve kuyruklarını bir Azure Depolama (klasik) hesabında depolar.

Not

Dayanıklı İşlevler için desteklenen depolama sağlayıcıları ve karşılaştırmaları hakkında daha fazla bilgi için Dayanıklı İşlevler depolama sağlayıcıları belgelerine bakın.

Azure Depolama sağlayıcısında tüm işlev yürütme işlemleri Azure Depolama kuyrukları tarafından yürütülmektedir. Düzenleme, varlık durumu ve geçmişi Azure Tablolarında depolanır. Azure Blobları ve blob kiralamaları, düzenleme örneklerini ve varlıkları birden çok uygulama örneğine (çalışan veya yalnızca VM olarak da bilinir) dağıtmak için kullanılır. Bu bölümde çeşitli Azure Depolama yapıtları ve bunların performansı ve ölçeklenebilirliği nasıl etkiledikleri hakkında daha ayrıntılı bilgi verebilirsiniz.

Depolama gösterimi

Görev hub'ı tüm örnek durumlarını ve tüm iletileri kalıcı olarak kalıcı hale getirme. Bunların bir düzenlemenin ilerleme durumunu izlemek için nasıl kullanıldığına hızlı bir genel bakış için görev hub'ı yürütme örneğine bakın.

Azure Depolama sağlayıcısı, aşağıdaki bileşenleri kullanarak depolamadaki görev hub'ını temsil eder:

• İki ile üç Azure Tablosu arasında. Geçmişleri ve örnek durumlarını temsil etmek için iki tablo kullanılır. Tablo Bölüm Yöneticisi etkinse, bölüm bilgilerini depolamak için üçüncü bir tablo tanıtılır.
• Etkinlik iletilerini bir Azure Kuyruğu depolar.
• Bir veya daha fazla Azure Kuyruğu örnek iletilerini depolar. Bu sözde denetim kuyruklarının her biri, örnek kimliğinin karması temelinde tüm örnek iletilerinin bir alt kümesine atanmış bir bölümü temsil eder.
• Kira blobları ve/veya büyük iletiler için kullanılan birkaç ek blob kapsayıcısı.

Örneğin, ile PartitionCount = 4 adlı xyz bir görev hub'ı aşağıdaki kuyrukları ve tabloları içerir:

Ardından, bu bileşenleri ve oynadıkları rolü daha ayrıntılı bir şekilde açıklayacağız.

Geçmiş tablosu

Geçmiş tablosu, bir görev hub'ı içindeki tüm düzenleme örnekleri için geçmiş olaylarını içeren bir Azure Depolama tablosudur. Bu tablonun adı TaskHubNameHistory biçimindedir. Örnekler çalıştırıldığında, bu tabloya yeni satırlar eklenir. Bu tablonun bölüm anahtarı, düzenlemenin örnek kimliğinden türetilir. Örnek kimlikleri varsayılan olarak rastgeledir ve Azure Depolama'da iç bölümlerin en iyi şekilde dağıtılmasını sağlar. Bu tablonun satır anahtarı, geçmiş olaylarını sıralamak için kullanılan bir sıra numarasıdır.

Bir düzenleme örneğinin çalışması gerektiğinde, Geçmiş tablosunun karşılık gelen satırları tek bir tablo bölümü içindeki bir aralık sorgusu kullanılarak belleğe yüklenir. Bu geçmiş olayları daha sonra orchestrator işlev kodunda yeniden yürütülerek daha önce denetim noktası belirtilmiş durumuna geri alınır. Durumu bu şekilde yeniden derlemek için yürütme geçmişinin kullanılması, Olay Kaynağını Belirleme düzeninden etkilenir.

İpucu

Geçmiş tablosunda depolanan düzenleme verileri, etkinlik ve alt düzenleyici işlevlerinden gelen çıkış yüklerini içerir. Dış olaylardan gelen yükler de Geçmiş tablosunda depolanır. Bir düzenleyicinin her yürütülmesi gerektiğinde tam geçmiş belleğe yüklendiğinden, yeterince büyük bir geçmiş belirli bir VM üzerinde önemli bir bellek baskısına neden olabilir. Düzenleme geçmişinin uzunluğu ve boyutu, büyük düzenlemelerin birden çok alt düzenlemeye bölünmesi veya çağırdığı etkinlik ve alt düzenleyici işlevleri tarafından döndürülen çıkışların boyutunun küçültülmesiyle azaltılabilir. Alternatif olarak, eş zamanlı olarak belleğe kaç düzenleme yüklendiğini sınırlamak için VM başına eşzamanlılık kısıtlamalarını azaltarak bellek kullanımını azaltabilirsiniz.

Örnekler tablosu

Instances tablosu, bir görev hub'ı içindeki tüm düzenleme ve varlık örneklerinin durumlarını içerir. Örnekler oluşturulduktan sonra bu tabloya yeni satırlar eklenir. Bu tablonun bölüm anahtarı düzenleme örneği kimliği veya varlık anahtarıdır ve satır anahtarı boş bir dizedir. Düzenleme veya varlık örneği başına bir satır vardır.

Bu tablo, koddan gelen örnek sorgu isteklerini ve durum sorgusu HTTP API çağrılarını karşılamak için kullanılır. Daha sonra daha önce bahsedilen Geçmiş tablosunun içeriğiyle tutarlı tutulur. Örnek sorgu işlemlerini bu şekilde verimli bir şekilde karşılamak için ayrı bir Azure Depolama tablosunun kullanılması, Komut ve Sorgu Sorumluluğu Ayrım (CQRS) düzeninden etkilenir.

İpucu

Instances tablosunun bölümlenmesi, çalışma zamanı performansı veya ölçeği üzerinde fark edilebilir bir etkisi olmadan milyonlarca düzenleme örneğini depolamasına olanak tanır. Ancak örnek sayısının çok örnekli sorgu performansı üzerinde önemli bir etkisi olabilir. Bu tablolarda depolanan veri miktarını denetlemek için eski örnek verilerini düzenli aralıklarla temizlemeyi göz önünde bulundurun.

Bölümler tablosu

Not

Bu tablo görev hub'ında yalnızca etkinleştirildiğinde Table Partition Manager gösterilir. Uygulamayı uygulamak için uygulamanızın host.json ayarını yapılandırınuseTablePartitionManagement.

Bölümler tablosu, Dayanıklı İşlevler uygulamasının bölümlerinin durumunu depolar ve bölümleri uygulamanızın çalışanları arasında dağıtmak için kullanılır. Bölüm başına bir satır vardır.

Kuyruklar

Orchestrator, varlık ve etkinlik işlevlerinin tümü işlev uygulamasının görev hub'ında iç kuyruklar tarafından tetiklenir. Kuyrukları bu şekilde kullanmak güvenilir "en az bir kez" ileti teslim garantisi sağlar. Dayanıklı İşlevler iki tür kuyruk vardır: denetim kuyruğu ve iş öğesi kuyruğu.

İş öğesi kuyruğu

Dayanıklı İşlevler görev hub'ı başına bir iş öğesi kuyruğu vardır. Bu temel bir kuyruk ve Azure İşlevleri'daki diğer queueTrigger kuyruklara benzer şekilde davranır. Bu kuyruk, tek seferde tek bir iletiyi sıralayarak durum bilgisi olmayan etkinlik işlevlerini tetikleme amacıyla kullanılır. Bu iletilerin her biri etkinlik işlevi girişleri ve yürütülecek işlev gibi ek meta veriler içerir. bir Dayanıklı İşlevler uygulamasının ölçeği birden çok VM'ye genişletildiğinde, bu VM'lerin tümü iş öğesi kuyruğundan görevleri almak için rekabet eder.

Denetim kuyrukları

Dayanıklı İşlevler görev hub'ı başına birden çok denetim kuyruğu vardır. Denetim kuyruğu , basit iş öğesi kuyruğundan daha karmaşıktır. Denetim kuyrukları, durum bilgisi olan düzenleyiciyi ve varlık işlevlerini tetikleme amacıyla kullanılır. Orchestrator ve varlık işlevi örnekleri durum bilgisi olan tekil öğeler olduğundan, her düzenlemenin veya varlığın aynı anda yalnızca bir çalışan tarafından işlenmesi önemlidir. Bu kısıtlamaya ulaşmak için her düzenleme örneği veya varlığı tek bir denetim kuyruğuna atanır. Bu denetim kuyrukları, her kuyruğun aynı anda yalnızca bir çalışan tarafından işlendiğinden emin olmak için çalışanlar arasında yük dengelemesi yapılır. Bu davranışla ilgili diğer ayrıntılar sonraki bölümlerde bulunabilir.

Denetim kuyrukları çeşitli düzenleme yaşam döngüsü ileti türleri içerir. Düzenleyici denetim iletileri, etkinlik işlevi yanıt iletileri ve zamanlayıcı iletileri örnek olarak verilebilir. Tek bir yoklamada bir denetim kuyruğundan 32 iletinin sırası kaldırılır. Bu iletiler yük verilerinin yanı sıra hedeflendiği düzenleme örneğini içeren meta verileri içerir. Aynı düzenleme örneği için birden çok sıralanmamış ileti amaçlanıyorsa, bunlar toplu iş olarak işlenir.

Denetim kuyruğu iletileri arka plan iş parçacığı kullanılarak sürekli yoklanır. Her kuyruk yoklamasının toplu iş boyutu, host.json ayarı tarafından controlQueueBatchSize denetlenmektedir ve varsayılan değeri 32'dir (Azure Kuyrukları tarafından desteklenen en yüksek değer). Bellekte arabelleğe alınan en fazla önceden oluşturulmuş denetim kuyruğu iletisi sayısı host.json ayarı tarafından controlQueueBufferThreshold denetleniyor. için controlQueueBufferThreshold varsayılan değer, barındırma planının türü de dahil olmak üzere çeşitli faktörlere bağlı olarak değişir. Bu ayarlar hakkında daha fazla bilgi için şema host.json belgelerine bakın.

İpucu

değerinin controlQueueBufferThreshold artırılması, tek bir düzenlemenin veya varlığın olayları daha hızlı işlemesine olanak tanır. Ancak, bu değerin artırılması daha yüksek bellek kullanımına da neden olabilir. Yüksek bellek kullanımı kısmen kuyruktan daha fazla ileti çekme ve kısmen belleğe daha fazla düzenleme geçmişleri getirmeden kaynaklanır. Bu nedenle değerini controlQueueBufferThreshold azaltmak bellek kullanımını azaltmanın etkili bir yolu olabilir.

Kuyruk yoklaması

Dayanıklı görev uzantısı, boşta kuyruk yoklamasının depolama işlemi maliyetleri üzerindeki etkisini azaltmak için rastgele bir üstel geri alma algoritması uygular. bir ileti bulunduğunda çalışma zamanı hemen başka bir ileti olup olmadığını denetler. İleti bulunamadığında, yeniden denemeden önce bir süre bekler. Sonraki başarısız kuyruk iletisi alma girişimlerinin ardından bekleme süresi, varsayılan olarak 30 saniye olan maksimum bekleme süresine ulaşana kadar artmaya devam eder.

En fazla yoklama gecikmesi, host.json dosyasındaki özelliği aracılığıyla maxQueuePollingInterval yapılandırılabilir. Bu özelliğin daha yüksek bir değere ayarlanması, ileti işleme gecikme sürelerinin daha yüksek olmasına neden olabilir. Daha yüksek gecikme süreleri yalnızca işlem yapılmadan geçen sürelerden sonra beklenir. Bu özelliğin daha düşük bir değere ayarlanması, depolama işlemlerinin artması nedeniyle depolama maliyetlerinin artmasına neden olabilir.

Not

Azure İşlevleri Tüketimi ve Premium planlarında çalışırken, Azure İşlevleri Ölçek Denetleyicisi her denetimi ve iş öğesi kuyruğunun her 10 saniyede bir yoklamasını sağlar. Bu ek yoklama, işlev uygulaması örneklerinin ne zaman etkinleştirileceğini belirlemek ve ölçeklendirme kararları almak için gereklidir. Yazma sırasında, bu 10 saniyelik aralık sabittir ve yapılandırılamaz.

Düzenleme başlatma gecikmeleri

Düzenleme örnekleri, görev hub'ının denetim kuyruklarından birine bir ExecutionStarted ileti yerleştirilerek başlatılır. Belirli koşullar altında, bir düzenlemenin çalıştırılacak şekilde zamanlanması ve gerçekten çalışmaya başlaması arasında çok saniyelik gecikmeler gözlemleyebilirsiniz. Bu zaman aralığı boyunca düzenleme örneği durumunda Pending kalır. Bu gecikmenin iki olası nedeni vardır:

• Geri yüklenmiş denetim kuyrukları: Bu örneğin denetim kuyruğu çok sayıda ileti içeriyorsa, iletinin ExecutionStarted çalışma zamanı tarafından alınması ve işlenmesi zaman alabilir. Düzenleme işlemleri çok sayıda olayı eşzamanlı olarak işlediğinde ileti kapsamları oluşabilir. Denetim kuyruğuna giden olaylar düzenleme başlatma olaylarını, etkinlik tamamlamalarını, dayanıklı zamanlayıcıları, sonlandırmayı ve dış olayları içerir. Bu gecikme normal koşullarda gerçekleşirse, daha fazla sayıda bölüme sahip yeni bir görev hub'ı oluşturmayı göz önünde bulundurun. Daha fazla bölüm yapılandırmak, çalışma zamanının yük dağıtımı için daha fazla denetim kuyruğu oluşturmasına neden olur. Her bölüm, en fazla 16 bölüm içeren bir denetim kuyruğuyla 1:1'e karşılık gelir.

• Yoklama gecikmelerini geri alma: Düzenleme gecikmelerinin bir diğer yaygın nedeni, denetim kuyrukları için daha önce açıklanan geri alma yoklama davranışıdır. Ancak bu gecikme yalnızca bir uygulamanın ölçeği iki veya daha fazla örneğe genişletildiğinde beklenir. Yalnızca bir uygulama örneği varsa veya düzenlemeyi başlatan uygulama örneği aynı zamanda hedef denetim kuyruğunun yoklama örneğiyse, kuyruk yoklama gecikmesi olmaz. Daha önce açıklandığı gibi host.json ayarları güncelleştirilerek yoklama gecikmelerini geri alma azaltılabilir.

Bloblar

Çoğu durumda Dayanıklı İşlevler verileri kalıcı hale getirmek için Azure Depolama Blobları kullanmaz. Ancak kuyruklar ve tablolar, Dayanıklı İşlevler tüm gerekli verileri bir depolama satırında veya kuyruk iletisinde kalıcı hale gelmesini engelleyebilecek boyut sınırlarına sahiptir. Örneğin, bir kuyrukta kalıcı olması gereken bir veri parçası seri hale getirildiğinde 45 KB'tan büyük olduğunda Dayanıklı İşlevler verileri sıkıştırır ve bunun yerine bir blobda depolar. Verileri blob depolamada bu şekilde kalıcı hale getiren Dayanıklı İşlev, tablo satırında veya kuyruk iletisinde bu bloba yönelik bir başvuruyu depolar. Dayanıklı İşlevler verileri alması gerektiğinde blobdan otomatik olarak getirir. Bu bloblar blob kapsayıcısında <taskhub>-largemessagesdepolanır.

Performans değerlendirmeleri

Büyük iletiler için ek sıkıştırma ve blob işlemi adımları, CPU ve G/Ç gecikme süresi maliyetleri açısından pahalı olabilir. Ayrıca, Dayanıklı İşlevler kalıcı verileri belleğe yüklemesi gerekir ve aynı anda birçok farklı işlev yürütmesi için bunu yapabilir. Sonuç olarak, büyük veri yüklerinin kalıcı hale yüklenmesi de yüksek bellek kullanımına neden olabilir. Bellek yükünü en aza indirmek için büyük veri yüklerini el ile (örneğin blob depolamada) kalıcı hale getirebilir ve bunun yerine bu verilere yapılan başvuruları geçirebilirsiniz. Bu şekilde kodunuz verileri yalnızca orchestrator işlevi yeniden yürütmeleri sırasında gereksiz yüklemelerden kaçınmak için gerektiğinde yükleyebilir. Ancak, işlevlerin yaşam süreleri boyunca farklı VM'lerde yürütülebileceği için disk içi durumunun kullanılabilir olması garanti edilmediğinden, yerel disklere yüklerin depolanması önerilmez.

Depolama hesabı seçimi

Dayanıklı İşlevler tarafından kullanılan kuyruklar, tablolar ve bloblar yapılandırılmış bir Azure Depolama hesabında oluşturulur. Kullanılacak hesap, host.json dosyasındaki durableTask/storageProvider/connectionStringName ayar (veya durableTask/azureStorageConnectionStringName Dayanıklı İşlevler 1.x'teki ayar) kullanılarak belirtilebilir.

Dayanıklı İşlevler 2.x

{
  "extensions": {
    "durableTask": {
      "storageProvider": {
        "connectionStringName": "MyStorageAccountAppSetting"
      }
    }
  }
}

Dayanıklı İşlevler 1.x

{
  "extensions": {
    "durableTask": {
      "azureStorageConnectionStringName": "MyStorageAccountAppSetting"
    }
  }
}

Belirtilmezse, varsayılan AzureWebJobsStorage depolama hesabı kullanılır. Ancak performansa duyarlı iş yükleri için varsayılan olmayan bir depolama hesabı yapılandırma önerilir. Dayanıklı İşlevler Azure Depolama'yı yoğun bir şekilde kullanır ve ayrılmış bir depolama hesabı kullanmak Dayanıklı İşlevler depolama kullanımını Azure İşlevleri konağın iç kullanımından ayırır.

Not

Azure Depolama sağlayıcısı kullanılırken standart genel amaçlı Azure Depolama hesapları gereklidir. Diğer tüm depolama hesabı türleri desteklenmez. Dayanıklı İşlevler için eski v1 genel amaçlı depolama hesaplarını kullanmanızı kesinlikle öneririz. Daha yeni v2 depolama hesapları, Dayanıklı İşlevler iş yükleri için önemli ölçüde daha pahalı olabilir. Azure Depolama hesabı türleri hakkında daha fazla bilgi için Depolama hesabına genel bakış belgelerine bakın.

Orchestrator ölçeği genişletme

Etkinlik işlevlerinin ölçeği esnek bir şekilde daha fazla VM eklenerek sınırsız olarak genişletilebilir, ancak tek tek düzenleyici örnekleri ve varlıkları tek bir bölümde yaşanacak şekilde kısıtlanır ve en fazla bölüm sayısı ayarınıza host.jsonbağlıdırpartitionCount.

Not

Genel olarak bakıldığında, orchestrator işlevleri basit olması amaçlanmıştır ve büyük miktarda bilgi işlem gücü gerektirmemelidir. Bu nedenle, düzenlemelerde harika aktarım hızı elde etmek için çok sayıda denetim kuyruğu bölümü oluşturmak gerekli değildir. Ağır işlerin çoğu durum bilgisi olmayan etkinlik işlevlerinde yapılmalıdır ve bunlar sonsuz ölçeklendirilebilir.

Denetim kuyruklarının sayısı host.json dosyasında tanımlanır. Aşağıdaki örnek host.json kod parçacığı özelliğini (veya durableTask/partitionCount Dayanıklı İşlevler 1.x'te) olarak 3ayarlardurableTask/storageProvider/partitionCount. Bölüm sayısı kadar denetim kuyruğu olduğunu unutmayın.

Dayanıklı İşlevler 2.x

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

Dayanıklı İşlevler 1.x

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

Görev hub'ı 1 ile 16 arasında bölümle yapılandırılabilir. Belirtilmezse, varsayılan bölüm sayısı 4'tür.

Düşük trafik senaryolarında uygulamanız ölçeklendirilir, bu nedenle bölümler az sayıda çalışan tarafından yönetilir. Örneğin, aşağıdaki diyagramı göz önünde bulundurun.

Önceki diyagramda, 1 ile 6 arasındaki düzenleyicilerin bölümler arasında yük dengelemesi olduğunu görüyoruz. Benzer şekilde, etkinlikler gibi bölümler çalışanlar arasında yük dengelenir. Bölümler, çalışmaya başlayan düzenleyicilerin sayısından bağımsız olarak çalışanlar arasında yük dengelenir.

Azure İşlevleri Tüketimi veya Elastik Premium planlarında çalışıyorsanız veya yük tabanlı otomatik ölçeklendirme yapılandırılmışsa, trafik arttıkça daha fazla çalışan ayrılır ve bölümler sonunda tüm çalışanlar arasında yük dengelemesi yapılır. Ölçeği genişletmeye devam ettiğimizde, sonunda her bölüm tek bir çalışan tarafından yönetilir. Diğer yandan, tüm çalışanlar genelinde etkinlikler yük dengelemeye devam edecektir. Bu, aşağıdaki görüntüde gösterilmiştir.

Herhangi bir anda en fazla eşzamanlı etkin düzenleme sayısının üst sınırı, uygulamanıza ayrılan çalışan sayısı ile değerinin maxConcurrentOrchestratorFunctionsçarpıdır. Bölümleriniz çalışanlar arasında tamamen ölçeklendirildiğinde bu üst sınır daha hassas hale getirilebilir. Ölçeği tamamen genişletildiğinde ve her çalışanın yalnızca tek bir İşlev ana bilgisayar örneği olacağından, etkin eşzamanlı düzenleyici örneklerinin en fazla sayısı, değeriniz maxConcurrentOrchestratorFunctionsolan bölüm sayısına eşit olur.

Not

Bu bağlamda etkin, bir düzenlemenin veya varlığın belleğe yüklendiği ve yeni olayları işlendiği anlamına gelir. Düzenleme veya varlık etkinlik işlevinin dönüş değeri gibi daha fazla olay bekliyorsa bellekten kaldırılır ve artık etkin olarak kabul edilmez. Düzenleme ve varlıklar daha sonra yalnızca işlenecek yeni olaylar olduğunda belleğe yeniden yüklenir. Tümü "Çalışıyor" durumunda olsalar bile tek bir VM'de çalışabilecek en fazla toplam düzenleme veya varlık sayısı pratik değildir. Tek sınırlama, eşzamanlı olarak etkin düzenleme veya varlık örneği sayısıdır.

Aşağıdaki görüntüde, daha fazla düzenleyicinin eklendiği ancak bazılarının etkin olmadığı ve gri renkte gösterildiği tam olarak ölçeklendirilmiş bir senaryo gösterilmektedir.

Ölçeği genişletme sırasında denetim kuyruğu kiraları, bölümlerin eşit dağıtıldığından emin olmak için İşlevler konak örnekleri arasında yeniden dağıtılabilir. Bu kiralamalar dahili olarak Azure Blob depolama kiralamaları olarak uygulanır ve her bir düzenleme örneğinin veya varlığın aynı anda yalnızca tek bir konak örneğinde çalıştığından emin olun. Görev hub'ı üç bölümle (ve dolayısıyla üç denetim kuyruğuyla) yapılandırıldıysa, düzenleme örnekleri ve varlıklar kira tutan üç konak örneğinde de yük dengelenebilir. Etkinlik işlevi yürütme kapasitesini artırmak için ek VM'ler eklenebilir.

Aşağıdaki diyagramda, Azure İşlevleri konağın ölçeği genişletilmiş bir ortamdaki depolama varlıklarıyla nasıl etkileşimde olduğu gösterilmektedir.

Önceki diyagramda gösterildiği gibi, tüm VM'ler iş öğesi kuyruğundaki iletiler için rekabet eder. Ancak, denetim kuyruklarından yalnızca üç VM ileti alabilir ve her VM tek bir denetim kuyruğu kilitler.

Düzenleme örnekleri ve varlıkları tüm denetim kuyruğu örnekleri arasında dağıtılır. Dağıtım, düzenlemenin örnek kimliği veya varlık adı ve anahtar çifti karma olarak yapılır. Düzenleme örneği kimlikleri varsayılan olarak rastgele GUID'lerdir ve örneklerin tüm denetim kuyruklarına eşit şekilde dağıtılmasını sağlar.

Genel olarak bakıldığında, orchestrator işlevleri basit olması amaçlanmıştır ve büyük miktarda bilgi işlem gücü gerektirmemelidir. Bu nedenle, düzenlemelerde harika aktarım hızı elde etmek için çok sayıda denetim kuyruğu bölümü oluşturmanız gerekmez. Ağır işlerin çoğu durum bilgisi olmayan etkinlik işlevlerinde yapılmalıdır ve bunlar sonsuz ölçeklendirilebilir.

Genişletilmiş oturumlar

Genişletilmiş oturumlar, iletileri işlemeyi bitirdikten sonra bile düzenlemeleri ve varlıkları bellekte tutan bir önbelleğe alma mekanizmasıdır . Genişletilmiş oturumları etkinleştirmenin tipik etkisi, temel alınan dayanıklı depoya karşı G/Ç'nin azaltılması ve genel olarak geliştirilmiş aktarım hızıdır.

host.json dosyasında olarak ayarlayarak durableTask/extendedSessionsEnabled true genişletilmiş oturumları etkinleştirebilirsiniz. Bu durableTask/extendedSessionIdleTimeoutInSeconds ayar, boşta kalan oturumun bellekte ne kadar süre tutulacağını denetlemek için kullanılabilir:

İşlevler 2.0

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

İşlevler 1.0

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

Bu ayarın dikkate alınması gereken iki olası dezavantajı vardır:

1. Boştaki örnekler bellekten hızlı bir şekilde kaldırılmadığından işlev uygulaması bellek kullanımında genel bir artış vardır.
2. Çok sayıda eşzamanlı, farklı, kısa süreli düzenleyici veya varlık işlevi yürütmesi varsa, aktarım hızı genel olarak düşebilir.

Örneğin, 30 saniye olarak ayarlanırsa durableTask/extendedSessionIdleTimeoutInSeconds , 1 saniyeden kısa sürede yürütülen kısa süreli bir düzenleyici veya varlık işlevi bölümü 30 saniye boyunca belleği kaplar. Ayrıca daha önce bahsedilen kotaya durableTask/maxConcurrentOrchestratorFunctions göre de sayar ve diğer düzenleyici veya varlık işlevlerinin çalışmasını engelleyebilir.

Genişletilmiş oturumların orchestrator ve varlık işlevleri üzerindeki özel etkileri sonraki bölümlerde açıklanmıştır.

Not

Genişletilmiş oturumlar şu anda yalnızca C# veya F# gibi .NET dillerinde desteklenmektedir. Diğer platformlar için olarak true ayarlanmasıextendedSessionsEnabled, etkinliğin sessizce yürütülememesi ve düzenlemeyle tetiklenen işlevler gibi çalışma zamanı sorunlarına yol açabilir.

Orchestrator işlevi yeniden yürütme

Daha önce belirtildiği gibi, orchestrator işlevleri Geçmiş tablosunun içeriği kullanılarak yeniden oynatılır. Varsayılan olarak, orchestrator işlev kodu bir dizi ileti denetim kuyruğundan her kaldırıldığında yeniden oynatılır. Fan-out, fan-in desenini kullanıyor olsanız ve tüm görevlerin tamamlanmasını bekliyor olsanız bile (örneğin, .NET'te, context.df.Task.all() JavaScript'te veya context.task_all() Python'da kullanarakTask.WhenAll()), zaman içinde toplu görev yanıtları işlendikçe yeniden yürütmeler gerçekleşir. Genişletilmiş oturumlar etkinleştirildiğinde, orchestrator işlev örnekleri bellekte daha uzun süre tutulur ve yeni iletiler tam geçmiş yeniden yürütmesi olmadan işlenebilir.

Genişletilmiş oturumların performans iyileştirmesi en sık aşağıdaki durumlarda gözlenir:

• Eşzamanlı olarak çalışan sınırlı sayıda düzenleme örneği olduğunda.
• Düzenlemelerde hızla tamamlanan çok sayıda sıralı eylem (örneğin, yüzlerce etkinlik işlevi çağrısı) olduğunda.
• Düzenlemelerde, aynı anda tamamlanan çok sayıda eylem ve fan-out vardır.
• Orchestrator işlevlerinin büyük iletileri işlemesi veya yoğun CPU kullanan veri işleme işlemleri yapması gerektiğinde.

Diğer tüm durumlarda, düzenleyici işlevleri için gözlemlenebilir performans geliştirmesi genellikle yoktur.

Not

Bu ayarlar yalnızca bir orchestrator işlevi tamamen geliştirilip test edildikten sonra kullanılmalıdır. Varsayılan agresif yeniden yürütme davranışı, geliştirme zamanında orchestrator işlev kodu kısıtlamaları ihlallerini algılamak için yararlı olabilir ve bu nedenle varsayılan olarak devre dışı bırakılır.

Performans hedefleri

Aşağıdaki tabloda, Performans ve Ölçek makalesinin Performans Hedefleri bölümünde açıklanan senaryolar için beklenen en yüksek aktarım hızı numaraları gösterilmektedir.

"Örnek", Azure Uygulaması Hizmeti'ndeki tek bir küçük (A1) VM üzerinde çalışan bir orchestrator işlevinin tek bir örneğini ifade eder. Her durumda, genişletilmiş oturumların etkinleştirildiği varsayılır. Gerçek sonuçlar, işlev kodu tarafından gerçekleştirilen CPU veya G/Ç çalışmasına bağlı olarak değişebilir.

Senaryo	Aktarım hızı üst sınırı
Sıralı etkinlik yürütme	Örnek başına saniyede 5 etkinlik
Paralel etkinlik yürütme (fan-out)	Örnek başına saniyede 100 etkinlik
Paralel yanıt işleme (fan-in)	Örnek başına saniyede 150 yanıt
Dış olay işleme	Örnek başına saniyede 50 olay
Varlık işlemi işleme	Saniyede 64 işlem

Beklediğiniz aktarım hızı numaralarını görmüyorsanız ve CPU ve bellek kullanımınız iyi durumda görünüyorsa, nedeninin depolama hesabınızın durumuyla ilgili olup olmadığını denetleyin. Dayanıklı İşlevler uzantısı bir Azure Depolama hesabına önemli bir yük yükleyebilir ve yeterince yüksek yükler depolama hesabının azaltmasıyla sonuçlanabilir.

İpucu

Bazı durumlarda, host.json ayarının değerini artırarak dış olayların, etkinlik fanının ve varlık işlemlerinin controlQueueBufferThreshold aktarım hızını önemli ölçüde artırabilirsiniz. Bu değeri varsayılan değerinin ötesine yükseltmek, Dayanıklı Görev Çerçevesi depolama sağlayıcısının bu olayları daha agresif bir şekilde önceden uygulamak için daha fazla bellek kullanmasına neden olur ve Bu da Azure Depolama denetim kuyruklarından gelen iletilerin sırasını kaldırmayla ilgili gecikmeleri azaltır. Daha fazla bilgi için host.json başvuru belgelerine bakın.

Yüksek aktarım hızı işleme

Azure Depolama arka ucu mimarisi, Dayanıklı İşlevler maksimum teorik performansına ve ölçeklenebilirliğine belirli sınırlamalar getirir. Testiniz Azure Depolama'da Dayanıklı İşlevler aktarım hızı gereksinimlerinizi karşılamadığını gösteriyorsa bunun yerine Dayanıklı İşlevler için Netherite depolama sağlayıcısını kullanmayı düşünmelisiniz.

Çeşitli temel senaryolarda ulaşılabilir aktarım hızını karşılaştırmak için Netherite depolama sağlayıcısının Temel Senaryoları belgeleri bölümüne bakın.

Netherite depolama arka ucu Microsoft Research tarafından tasarlanmış ve geliştirilmiştir. Azure Sayfa Blobları'nın üzerinde Azure Event Hubs ve FASTER veritabanı teknolojisini kullanır. Netherite tasarımı, diğer sağlayıcılara kıyasla düzenleme ve varlıkların önemli ölçüde daha yüksek aktarım hızına sahip işlenmesini sağlar. Bazı karşılaştırma senaryolarında, aktarım hızının varsayılan Azure Depolama sağlayıcısıyla karşılaştırıldığında bir büyüklük sırasına göre daha fazla arttığı gösterilmiştir.

Dayanıklı İşlevler için desteklenen depolama sağlayıcıları ve karşılaştırmaları hakkında daha fazla bilgi için Dayanıklı İşlevler depolama sağlayıcıları belgelerine bakın.

Sonraki adımlar

Olağanüstü durum kurtarma ve coğrafi dağıtım hakkında bilgi edinin