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

Bu belgede Dayanıklı İşlevler Azure Depolama sağlayıcısının özellikleri açıklanır ve performans ve ölçeklenebilirlik özelliklerine odaklanılmaktadır. 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 bunların karşılaştırması 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ışanlar veya yalnızca VM'ler 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 sağlanır.

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ı TaskHubNameGeçmişi biçimindedir. Örnekler çalıştırılırken 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ıştırılması 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 koduna yeniden yürütülerek daha önce denetim noktası belirtilmiş durumuna döndürülü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'de ö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 yüklenen düzenleme sayısını 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'ının 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 başına bir satır veya varlık örneği vardır.

Bu tablo hem koddan gelen örnek sorgu isteklerini hem de durum sorgusu HTTP API çağrılarını karşılamak için kullanılır. Sonunda 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 belirgin 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. Bunu uygulamak için uygulamanızın host.json dosyasında ayarı 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ın bu şekilde kullanılması 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. Dayanıklı İşlevler bir uygulamanı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'da görev hub'ı başına birden çok denetim kuyruğu vardır. Denetim kuyruğu, daha 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 daha fazla ayrıntıyı sonraki bölümlerde bulabilirsiniz.

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 buna örnek olarak verilebilir. Tek bir yoklamada bir denetim kuyruğundan 32 iletinin sırası kaldırılacaktı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 dosyasındaki controlQueueBatchSize ayar tarafından denetlenmektedir ve varsayılan değeri 32'dir (Azure Kuyrukları tarafından desteklenen en yüksek değer). Bellekte arabelleğe alınan önceden oluşturulmuş denetim kuyruğu iletilerinin en fazla sayısı host.json dosyasındaki controlQueueBufferThreshold ayar tarafından 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 host.json şeması 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 kuyrukta daha fazla ileti çekme ve kısmen belleğe daha fazla düzenleme geçmişleri getirme nedeniyledir. Bu nedenle değerini controlQueueBufferThreshold azaltmak bellek kullanımını azaltmanın etkili bir yolu olabilir.

Kuyruk yoklama

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 iletiyi denetler. İleti bulunamadığında, yeniden denemeden önce bir süre bekler. Sonraki başarısız kuyruk iletisi alma denemelerinden sonra, 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 artmasına neden olabilir. Daha yüksek gecikme süreleri yalnızca işlem yapılmama sürelerinden sonra beklenir. Bu özelliğin daha düşük bir değere ayarlanması, artan depolama işlemleri 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ğu 10 saniyede bir yoklar. 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ıyla 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ğu ile 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ını kullanmaz. Ancak kuyruklar ve tablolar, Dayanıklı İşlevler tüm gerekli verileri depolama satırı veya kuyruk iletisinde kalıcı hale getirebilecek boyut sınırlarına sahiptir. Örneğin, bir kuyruğa kalıcı hale getirmesi gereken bir veri parçası seri hale getirildiğinde 45 KB'tan büyükse, 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, bu bloba başvuruyu tablo satırında veya kuyruk iletisinde depolar. Dayanıklı İşlevler verileri alması gerektiğinde blobdan otomatik olarak getirir. Bu bloblar blob kapsayıcısında <taskhub>-largemessagesdepolanır.

Performansla ilgili önemli noktalar

Büyük iletiler için ek sıkıştırma ve blob işlem 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 düzenleyici 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 durumun kullanılabilir olması garanti edilmediğinden yüklerin yerel disklere 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ğı tarafından iç kullanımdan ayırır.

Not

Standart genel amaçlı Azure Depolama hesapları, Azure Depolama sağlayıcısı kullanılırken 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şletilse de, tek tek düzenleyici örnekleri ve varlıkları tek bir bölümde yer almak için kısıtlanır ve bölüm sayısı üst sınırı ayarınızda host.jsonsınırlanırpartitionCount.

Not

Genel olarak, orchestrator işlevleri hafif olması amaçlanır ve büyük miktarlarda bilgi işlem gücü gerektirmez. Bu nedenle, düzenlemelerde mükemmel 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, sonsuz ölçeklendirilebilen durum bilgisi olmayan etkinlik işlevlerinde yapılmalıdır.

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. Örnek olarak 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üketim 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 sağlar. Ölçeği genişletmeye devam ederse, sonunda her bölüm tek bir çalışan tarafından yönetilir. Öte yandan, tüm çalışanlar genelinde etkinlikler yük dengelemeye devam edecektir. Bu, aşağıdaki resimde gösterilmiştir.

Herhangi bir zamanda eş zamanlı etkin düzenleme sayısı üst sınırı, uygulamanıza ayrılan çalışan sayısının değerinin çarpımaxConcurrentOrchestratorFunctionsdeğerine eşittir. Bölümleriniz çalışanlar arasında tamamen ölçeklendirildiğinde bu üst sınır daha hassas hale getirilebilir. Ölçeği tam olarak genişletildiğinde ve her çalışanın yalnızca tek bir İşlev ana bilgisayar örneği olacağından, etkin eş zamanlı düzenleyici örneği sayısı üst sınırı, değerinizmaxConcurrentOrchestratorFunctionsolan 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ışabilen pratik en fazla toplam düzenleme veya varlık sayısı yoktur. 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, bölümlerin eşit dağıtıldığından emin olmak için denetim kuyruğu kiraları İş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. Bir 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 dengelemesi yapılabilir. 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, orchestrator işlevleri hafif olması amaçlanır ve büyük miktarlarda bilgi işlem gücü gerektirmez. Bu nedenle, düzenlemelerde mükemmel 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, sonsuz ölçeklendirilebilen durum bilgisi olmayan etkinlik işlevlerinde yapılmalıdır.

Genişletilmiş oturumlar

Genişletilmiş oturumlar, iletileri işlemeyi bitirdikten sonra bile düzenleme 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/extendedSessionsEnabledtrue 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ı, ayrı, 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 sayılır ve diğer orchestrator veya varlık işlevlerinin çalışmasını engelleyebilir.

Genişletilmiş oturumların düzenleyici ve varlık işlevleri üzerindeki belirli 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 de belirtildiği gibi, orchestrator işlevleri Geçmiş tablosunun içeriği kullanılarak yeniden yürütülür. Varsayılan olarak orchestrator işlev kodu, bir dizi iletinin denetim kuyruğundan her kuyruğa alınmasında yeniden yürütülür. Fan-out, fan-in desenini kullanıyor 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 oluşan yeniden yürütmeler olacaktır. Genişletilmiş oturumlar etkinleştirildiğinde orchestrator işlevi ö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 artışı en çok aşağıdaki durumlarda gözlemlenir:

• 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 yapılır.
• Düzenleyici işlevlerinin büyük iletileri işlemesi veya yoğun CPU kullanan veri işlemesi 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 düzenleyici 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 App Service'daki tek bir küçük (A1) VM üzerinde çalışan bir düzenleyici 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ışmaları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 (yayma)	Ö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ı sayıları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 ölçüde yük bindirebilir ve yeterince yüksek yükler depolama hesabının azaltmasıyla sonuçlanabilir.

İpucu

Bazı durumlarda host.json dosyasındaki ayarın değerini artırarak dış olayların, etkinlik desteğinin ve varlık işlemlerinin controlQueueBufferThreshold aktarım hızını önemli ölçüde artırabilirsiniz. Bu değerin varsayılanın ötesine yükseltilmesi 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 olarak 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 en yüksek teorik performans ve ölçeklenebilirlik sınırlamalarını getirir. Testinizde 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ı belgelerinin Temel Senaryoları bölümüne bakın.

Netherite depolama arka ucu Microsoft Research tarafından tasarlanmış ve geliştirilmiştir. Azure Sayfa Blobları üzerinde Azure Event Hubs ve DAHA HIZLI veritabanı teknolojisini kullanır. Netherite'ın 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 bunların karşılaştırması 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