Azure Logic Apps'te azaltma sorunlarını (429 - "Çok fazla istek" hatası) işleme
Şunlar için geçerlidir: Azure Logic Apps (Tüketim + Standart)
Mantıksal uygulama iş akışınızda azaltma yaşanıyorsa ve istek sayısı hedefin belirli bir süre boyunca işleyebildiği hızı aştığında gerçekleşirse, "HTTP 429 Çok fazla istek var" hatasını alırsınız. Azaltma; gecikmeli bilgi işlem, azaltılmış performans hızı ve belirtilen yeniden deneme ilkesinin aşılması gibi sorunlar doğurabilir.
Örneğin, tüketim iş akışındaki aşağıdaki SQL Server eylemi azaltma sorunu bildiren 429 hatasını gösterir:
Aşağıdaki bölümlerde iş akışınızın azaltmayla karşılaşabileceği ortak düzeyler açıklanmaktadır:
Mantıksal uygulama kaynak azaltma
Azure Logic Apps'in kendi aktarım hızı sınırları vardır. Mantıksal uygulama kaynağınız bu sınırları aşarsa, mantıksal uygulama kaynağınız yalnızca belirli bir iş akışı örneği veya çalıştırma değil kısıtlanır.
Bu düzeyde azaltma olaylarını bulmak için şu adımları izleyin:
Mantıksal uygulama kaynak menüsündeki İzleme'nin altında Ölçümler'i seçin.
Grafik Başlığı'nın altında Grafiğe başka bir ölçüm çubuğu ekleyen Ölçüm ekle'yi seçin.
İlk ölçüm çubuğundaki Ölçüm listesinden Eylem Kısıtlanmış Olaylar'ı seçin. Toplama listesinden Sayı'yı seçin.
İkinci ölçüm çubuğundaki Ölçüm listesinden Kısıtlanmış Olayları Tetikle'yi seçin. Toplama listesinden Sayı'yı seçin.
Grafikte artık mantıksal uygulama iş akışınızdaki hem eylemler hem de tetikleyiciler için kısıtlanmış olaylar gösterilir. Daha fazla bilgi için bkz . Azure Logic Apps'te iş akışı durumu ve performansı için ölçümleri görüntüleme.
Bu düzeyde azaltmayı işlemek için aşağıdaki seçeneklere sahipsiniz:
Aynı anda çalışabilecek iş akışı örneklerinin sayısını sınırlayın.
Varsayılan olarak, iş akışınızın tetikleyici koşulu aynı anda birden çok kez karşılanırsa, bu tetikleyicinin birden çok örneği tetikler ve eşzamanlı olarak veya paralel olarak çalışır. Her tetikleyici örneği, önceki iş akışı örneğinin çalışması tamamlanmadan önce tetiklenir.
Eşzamanlı olarak çalıştırabilen varsayılan tetikleyici örneği sayısı sınırsız olsa da tetikleyicinin eşzamanlılık ayarını açarak bu sayıyı sınırlayabilir ve gerekirse varsayılan değer dışında bir sınır seçebilirsiniz.
Yüksek aktarım hızı modunu etkinleştirin.
Tüketim iş akışının, 5 dakikalık bir sıralı aralıkta çalıştırabileceğiniz eylem sayısı için varsayılan sınırı vardır. Bu sınırı en fazla eylem sayısına yükseltmek için mantıksal uygulama kaynağınızda yüksek aktarım hızı modunu açın.
Standart iş akışının herhangi bir aralıkta çalıştırabileceğiniz eylem sayısı sınırı yoktur.
Tetikleyicilerde dizi eşleşmesini kaldırma veya "Bölme Açık" davranışını devre dışı bırakın.
Tetikleyici, işlenmek üzere kalan iş akışı eylemleri için bir dizi döndürürse, tetikleyicinin Bölünmüş Ayarı dizi öğelerini böler ve her dizi öğesi için bir iş akışı örneği başlatır. Bu davranış, Birden çok eşzamanlı çalıştırmayı Bölme Sınırına kadar etkili bir şekilde tetikler.
Azaltmayı denetlemek için tetikleyicinin Split On davranışını kapatın ve iş akışınızın çağrı başına tek bir öğeyi işlemek yerine tüm diziyi tek bir çağrıyla işlemesini sağlayın.
Eylemleri birden çok, daha küçük iş akışı halinde yeniden düzenleyin.
Daha önce belirtildiği gibi Tüketim mantıksal uygulaması iş akışı, 5 dakikalık bir süre boyunca çalıştırabileceğiniz varsayılan eylem sayısıyla sınırlıdır. Yüksek aktarım hızı modunu etkinleştirerek bu sınırı artırabilirsiniz, ancak her iş akışında çalıştırılan eylem sayısının sınırın altında kalması için iş akışınızın eylemlerini daha küçük iş akışlarına bölmek isteyip istemediğinizi de düşünebilirsiniz. Bu şekilde, tek bir iş akışının yükünü azaltır ve yükü birden çok iş akışına dağıtırsınız. Bu çözüm, büyük veri kümelerini işleyen veya her döngü yinelemesinde eşzamanlı olarak çalışan çok sayıda eylem, döngü yinelemesi veya eylem çalıştırarak eylem yürütme sınırını aşan eylemler için daha iyi çalışır.
Örneğin, aşağıdaki Tüketim iş akışı bir SQL Server veritabanından tablo almak için tüm işleri yapar ve her tablodan satırları alır. Her bir döngü için her tablo arasında eşzamanlı olarak yinelenir, böylece Satırları al eylemi her tablo için satırları döndürür. Bu tablolardaki veri miktarına bağlı olarak, bu eylemler eylem yürütme sınırını aşabilir.
Yeniden düzenlemeden sonra özgün iş akışı bir üst iş akışına ve bir alt iş akışına bölünür.
Aşağıdaki üst iş akışı SQL Server'dan tabloları alır ve sonra satırları almak için her tablo için alt iş akışını çağırır:
Aşağıdaki alt iş akışı, her tablonun satırlarını almak için üst iş akışı tarafından çağrılır:
Bağlayıcı azaltma
Her bağlayıcının kendi azaltma sınırları vardır ve bunu her bağlayıcının teknik başvuru sayfasında bulabilirsiniz. Örneğin, Azure Service Bus bağlayıcısının dakikada en fazla 6.000 çağrıya izin veren bir azaltma sınırı vardır; SQL Server bağlayıcısı ise işlem türüne göre değişen azaltma sınırlarına sahiptir.
HTTP gibi bazı tetikleyiciler ve eylemler, özel durum işlemeyi uygulamak için yeniden deneme ilkesi sınırlarına göre özelleştirebileceğiniz bir "yeniden deneme ilkesine" sahiptir. Bu ilke, özgün istek başarısız olduğunda veya zaman aşımına uğradıklarında ve 408, 429 veya 5xx yanıtla sonuçlandığında tetikleyicinin veya eylemin isteği ne sıklıkta yeniden denendiğini belirtir. Bu nedenle azaltma başladığında ve 429 hatası döndürdüğünde Logic Apps, desteklendiği yerde yeniden deneme ilkesini izler.
Tetikleyicinin veya eylemin yeniden deneme ilkelerini destekleyip desteklemediğini öğrenmek için tetikleyicinin veya eylemin ayarlarını denetleyin. Tetikleyicinin veya eylemin yeniden deneme girişimlerini görüntülemek için mantıksal uygulamanızın çalıştırma geçmişine gidin, gözden geçirmek istediğiniz çalıştırmayı seçin ve girişler, çıkışlar ve yeniden denemelerle ilgili ayrıntıları görüntülemek için bu tetikleyiciyi veya eylemi genişletin.
Aşağıdaki Tüketim iş akışı örneği, bir HTTP eylemi için bu bilgileri nerede bulabileceğinizi gösterir:
Yeniden deneme geçmişi hata bilgileri sağlasa da, bağlayıcı azaltma ve hedef azaltma arasında fark oluşturmada sorun yaşayabilirsiniz. Bu durumda, yanıtın ayrıntılarını gözden geçirmeniz veya kaynağı tanımlamak için azaltma aralığı hesaplamaları yapmanız gerekebilir.
Çok kiracılı Azure Logic Apps'teki Tüketim mantıksal uygulaması iş akışları için azaltma bağlantı düzeyinde gerçekleşir.
Bu düzeyde azaltmayı işlemek için aşağıdaki seçeneklere sahipsiniz:
İş akışının verileri işlenmek üzere bölümlemesi için tek bir eylem için birden çok bağlantı ayarlayın.
Bir eylemin isteklerini aynı kimlik bilgilerini kullanarak birden çok bağlantıya bölerek iş yükünü dağıtıp dağıtamayacağınızı düşünün.
Örneğin, iş akışınızın bir SQL Server veritabanından tablo aldığını ve ardından her tablodan satırları aldığını varsayalım. İşlemeniz gereken satır sayısına bağlı olarak, işleme için toplam satır sayısını daha küçük kümelere bölmek için birden çok bağlantı ve her döngü için birden çok döngü kullanabilirsiniz. Bu senaryoda, toplam satır sayısını ikiye bölmek için her döngü için iki tane kullanılır. her döngü için ilk yarısı alan bir ifade kullanır. Diğer Her döngü için ikinci yarıyı alan farklı bir ifade kullanır, örneğin:
İfade 1:
take()İşlev bir koleksiyonun önüne geçer. Daha fazla bilgi için işlevinetake()bakın.@take(collection-or-array-name, div(length(collection-or-array-name), 2))İfade 2:
skip()İşlev bir koleksiyonun ön kısmını kaldırır ve diğer tüm öğeleri döndürür. Daha fazla bilgi için işlevineskip()bakın.@skip(collection-or-array-name, div(length(collection-or-array-name), 2))Aşağıdaki Tüketim iş akışı örneği, bu ifadeleri nasıl kullanabileceğinizi gösterir:
Her eylem için farklı bir bağlantı ayarlayın.
Eylemler aynı hizmete veya sisteme bağlanıp aynı kimlik bilgilerini kullansa bile her eylemin isteklerini kendi bağlantılarına yayarak iş yükünü dağıtıp dağıtamayacağınızı düşünün.
Örneğin, iş akışınızın tabloları bir SQL Server veritabanından aldığını ve her tablodaki her satırı aldığını varsayalım. Tabloları alma işleminin tek bir bağlantı kullanması için ayrı bağlantılar kullanabilirsiniz. Bu arada her satırı almak başka bir bağlantı kullanır.
Aşağıdaki örnekte, her eylem için farklı bir bağlantı oluşturan ve kullanan bir Tüketim iş akışı gösterilmektedir:
"Her bir için" döngüsündeki eşzamanlılığı veya paralelliği değiştirin.
Varsayılan olarak, "Her biri için" döngü yinelemeleri eşzamanlılık sınırına kadar aynı anda çalışır. "Her biri için" döngüsü içinde kısıtlanan bir bağlantınız varsa, paralel olarak çalışan döngü yinelemelerinin sayısını azaltabilirsiniz. Daha fazla bilgi için, aşağıdaki belgelere bakın:
Hedef hizmet veya sistem azaltma
Bağlayıcının kendi azaltma sınırları olsa da, bağlayıcı tarafından çağrılan hedef hizmet veya sistemin de azaltma sınırları olabilir. Örneğin, Microsoft Exchange Server'daki bazı API'lerin azaltma sınırları Office 365 Outlook bağlayıcısından daha katıdır.
Varsayılan olarak, mantıksal uygulamanın iş akışı örnekleri ve bu örneklerin içindeki tüm döngüler veya dallar paralel olarak çalışır. Bu davranış, birden çok örneğin aynı uç noktayı aynı anda çağırabileceği anlamına gelir. Her örnek diğerinin varlığını bilmez, bu nedenle başarısız eylemleri yeniden deneme girişimleri, birden çok çağrının aynı anda çalışmaya çalıştığı yarış koşulları oluşturabilir, ancak başarılı olmak için azaltma başlamadan önce bu çağrıların hedef hizmete veya sisteme ulaşması gerekir.
Örneğin, 100 öğe içeren bir diziniz olduğunu varsayalım. Dizide yineleme yapmak için "Her biri için" döngüsü kullanır ve paralel yineleme sayısını 20 veya geçerli varsayılan sınırla kısıtlayabileceğiniz döngünün eşzamanlılık denetimini açarsınız. Bu döngünün içinde bir eylem dizideki bir öğeyi SQL Server veritabanına ekler ve bu da saniyede yalnızca 15 çağrıya izin verir. Bu senaryo bir azaltma sorununa neden olur çünkü bir yeniden deneme kapsamı birikir ve hiçbir zaman çalıştırılamaz.
Aşağıdaki tabloda, eylemin yeniden deneme aralığı 1 saniye olduğunda döngüde ne olacağıyla ilgili zaman çizelgesi açıklanmaktadır:
| Belirli bir noktaya | Çalıştırılacak eylem sayısı | Başarısız olan eylem sayısı | Bekleyen yeniden deneme sayısı |
|---|---|---|---|
| T + 0 saniye | 20 ekleme | SQL sınırı nedeniyle 5 başarısız oldu | 5 yeniden deneme |
| T + 0,5 saniye | Önceki 5 yeniden denemenin beklemesi nedeniyle 15 ekleme | Önceki SQL sınırı 0,5 saniye daha geçerli olduğundan 15'in tümü başarısız oldu | 20 yeniden deneme (önceki 5 + 15 yeni) |
| T + 1 saniye | 20 ekleme | SQL sınırı nedeniyle 5 başarısız ve önceki 20 yeniden deneme | 25 yeniden deneme (önceki 20 + 5 yeni) |
Bu düzeyde azaltmayı işlemek için aşağıdaki seçeneklere sahipsiniz:
Her birinin tek bir işlemi işlemesi için tek tek iş akışları oluşturun.
Bu bölümdeki örnek SQL Server senaryosuna devam ederek, dizi öğelerini Azure Service Bus kuyruğu gibi bir kuyruğa yerleştiren bir iş akışı oluşturabilirsiniz. Ardından, bu kuyruktaki her öğe için yalnızca ekleme işlemini gerçekleştiren başka bir iş akışı oluşturursunuz. Bu şekilde, herhangi bir zamanda yalnızca bir iş akışı örneği çalıştırılır ve bu da ekleme işlemini tamamlar ve kuyruktaki bir sonraki öğeye geçer veya örnek 429 hataları alır ancak üretim dışı yeniden denemeler yapmaya çalışmaz.
Her eylem için bir alt veya iç içe iş akışı çağıran bir üst iş akışı oluşturun. Ebeveynin sonucuna göre farklı alt iş akışlarını çağırması gerekiyorsa, hangi alt iş akışının çağrılabileceğini belirleyen bir koşul eylemi veya anahtar eylemi kullanabilirsiniz. Bu düzen, çağrı veya işlem sayısını azaltmanıza yardımcı olabilir.
Örneğin, her birinin e-posta hesabınızı "Başarılı" veya "Başarısızlık" gibi belirli bir konu için dakikada bir denetlediği yoklama tetikleyicisi olan iki iş akışınız olduğunu varsayalım. Bu kurulum saatte 120 çağrıyla sonuçlandı. Bunun yerine, dakikada bir yoklayan ancak konunun "Başarılı" veya "Başarısız" olmasına bağlı olarak çalışan bir alt iş akışı çağıran tek bir üst iş akışı oluşturursanız, yoklama denetimlerinin sayısını yarıya veya bu durumda 60'a kesersiniz.
Toplu işlemeyi ayarlayın. (Yalnızca tüketim iş akışları)
Hedef hizmet toplu işlemleri destekliyorsa, öğeleri tek tek değil, gruplar veya toplu işlerde işleyerek azaltmayı giderebilirsiniz. Toplu işlem çözümünü uygulamak için bir "toplu iş alıcısı" mantıksal uygulama iş akışı ve bir "toplu iş göndereni" mantıksal uygulama iş akışı oluşturursunuz. Toplu iş göndereni, belirtilen ölçütleriniz karşılanana kadar iletileri veya öğeleri toplar ve sonra bu iletileri veya öğeleri tek bir grupta gönderir. Toplu iş alıcısı bu grubu kabul eder ve bu iletileri veya öğeleri işler. Daha fazla bilgi için bkz . Gruplarda toplu işlem iletileri.
Yoklama sürümleri yerine tetikleyiciler ve eylemler için web kancası sürümlerini kullanın.
Neden? Yoklama tetikleyicisi, hedef hizmeti veya sistemi belirli aralıklarla denetlemeye devam eder. Her saniye gibi çok sık aralıklar azaltma sorunlarına neden olabilir. Ancak, HTTP Web Kancası gibi bir web kancası tetikleyicisi veya eylemi, hedef hizmete veya sisteme yalnızca tek bir çağrı oluşturur. Bu çağrı abonelik zamanında gerçekleşir ve hedefin tetikleyiciyi veya eylemi yalnızca bir olay gerçekleştiğinde bildirimde bulunmasını ister. Bu şekilde tetikleyicinin veya eylemin hedefi sürekli olarak denetlemesi gerekmez.
Bu nedenle, hedef hizmet veya sistem web kancalarını destekliyorsa veya web kancası sürümüne sahip bir bağlayıcı sağlıyorsa, bu seçenek yoklama sürümünü kullanmaktan daha iyidir. Web kancası tetikleyicilerini ve eylemlerini tanımlamak için, türe
ApiConnectionWebhooksahip olduklarını veya yinelenme belirtmenizi gerektirmediklerini onaylayın. Daha fazla bilgi için bkz . APIConnectionWebhook tetikleyicisi ve APIConnectionWebhook eylemi.