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 (istek sayısı hedefin belirli bir süre boyunca işleyebildiği hızı aştığında gerçekleşir) "HTTP 429 Çok fazla istek var" hatasını alırsınız. Azaltma gecikmeli veri işleme, düşük performans hızı ve belirtilen yeniden deneme ilkesini aşma gibi hatalar gibi sorunlar oluşturabilir.
Örneğin, bir 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üzeydeki azaltma olaylarını bulmak için şu adımları izleyin:
Azure portal mantıksal uygulama kaynağınızı açın.
Mantıksal uygulama kaynak menüsündeki İzleme'nin altında Ölçümler'i seçin.
Grafik Başlığı'nın altında Ölçüm ekle'yi seçerek grafiğe başka bir ölçüm çubuğu ekleyin.
İlk ölçüm çubuğundaki Ölçümlistesinden Eylem Kısıtlanmış Olaylar'ı seçin. Toplamalistesinden Sayı'yı seçin.
İkinci ölçüm çubuğundaki Ölçüm listesinde Kısıtlanmış Olayları Tetikle'yi seçin. Toplamalistesinden 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ışı örneği 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 tetiklenip eşzamanlı veya paralel olarak çalıştırılı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ışı, 5 dakikalık bir sıralı zaman aralığında çalıştırılacak eylem sayısı için varsayılan bir sınıra sahiptir. Bu sınırı maksimum 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ışında herhangi bir aralıkta çalıştırılacak eylem sayısı sınırı yoktur.
Tetikleyicilerde dizi uyuşmazlığı veya "Bölme" davranışını devre dışı bırakın.
Tetikleyici, işlenmek üzere kalan iş akışı eylemleri için bir dizi döndürürse, tetikleyicinin Split On ayarı dizi öğelerini böler ve her dizi öğesi için bir iş akışı örneği başlatır. Bu davranış, Bölme Sınırına kadar birden çok eşzamanlı çalıştırmayı 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 tek bir çağrıyla dizinin tamamını 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ırabilecek 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ü yinelemesi içinde eylem yürütme sınırını aşan çok sayıda eşzamanlı çalışan eylem, döngü yinelemesi veya eylem oluşturan 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 için döngüsü, satırları al eyleminin her tablonun satırlarını döndürmesi için her tabloda aynı anda yinelenir. 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 alt iş akışına bölünür.
Aşağıdaki üst iş akışı, tabloları SQL Server alır ve sonra satırları almak için her tablonun 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, her bağlayıcının teknik başvuru sayfasında bulabileceğiniz kendi azaltma sınırları vardır. Örneğin, Azure Service Bus bağlayıcısı dakikada en fazla 6.000 çağrıya izin veren bir azaltma sınırına sahipken, SQL Server bağlayıcısı 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ıtıyla sonuçlandığında tetikleyicinin veya eylemin isteği ne sıklıkta yeniden denendiğini belirtir. Bu nedenle, azaltma başlatıldığında ve 429 hatası döndürdüğünde Logic Apps, desteklendiğinde 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 denemeler hakkındaki 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. Tümleştirme hizmeti ortamında (ISE) çalışan mantıksal uygulama iş akışları için, çok kiracılı Azure Logic Apps'te çalıştıkları için ISE olmayan bağlantılarda azaltma devam eder. Ancak ISE bağlayıcıları tarafından oluşturulan ISE bağlantıları ISE'nizde çalıştıkları için kısıtlanmıyor.
Bu düzeyde azaltmayı işlemek için aşağıdaki seçeneklere sahipsiniz:
İş akışının verileri işlenmek üzere bölümleyebilmesi için tek bir eylem için birden çok bağlantı ayarlayın.
Bir eylemin isteklerini aynı kimlik bilgilerini kullanarak aynı hedefe birden çok bağlantı arasında bölerek 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 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 üzere birden çok bağlantı ve her döngü için birden çok for kullanabilirsiniz. Bu senaryoda, toplam satır sayısını ikiye bölmek için her bir döngü için iki tane kullanılır. İlk For each döngüsü, ilk yarısını alan bir ifade kullanır. Diğer Her döngü için ikinci yarısını 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ğlandığında ve aynı kimlik bilgilerini kullandığında 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 bir bağlantı kullanması için ayrı bağlantılar kullanabilirsiniz, her satırın alınmasında ise başka bir bağlantı kullanılı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 biri için" döngüsünde 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 sistem de azaltma sınırlarına sahip olabilir. Örneğin, Microsoft Exchange Server'deki bazı API'ler Office 365 Outlook bağlayıcısından daha katı azaltma sınırlarına sahiptir.
Varsayılan olarak, mantıksal uygulamanın iş akışı örnekleri ve bu örneklerin içindeki döngüler veya dallar paralel olarak çalıştırılır. Bu davranış, birden çok örneğin aynı uç noktayı aynı anda çağırabileceği anlamına gelir. Her örnek diğerinin varlığından haberdar değildir, 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ırsınız 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 diziden bir öğeyi SQL Server veritabanına ekler ve bu da saniyede yalnızca 15 çağrıya izin verir. Bu senaryo, bir yeniden deneme kapsamı biriktiği ve hiçbir zaman çalıştırılmadığı için azaltma sorununa neden olur.
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 kuyruğa koyan Azure Service Bus kuyruğu gibi 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; bu da ekleme işlemini tamamlar ve kuyruktaki bir sonraki öğeye geçer veya örnek 429 hataları alır ancak verimsiz yeniden denemeleri denemez.
Her eylem için bir alt veya iç içe iş akışı çağıran bir üst iş akışı oluşturun. Ebeveynin, üst öğesinin 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 biri "Başarılı" veya "Başarısız" gibi belirli bir konu için e-posta hesabınızı dakikada bir denetleyan bir 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ı" mı yoksa "Başarısız" mı olduğuna 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 ayarlama. (Yalnızca tüketim iş akışları)
Hedef hizmet toplu işlemleri destekliyorsa, öğeleri tek tek değil gruplar veya toplu işler halinde işleyerek azaltmayı giderebilirsiniz. Toplu işlem çözümünü uygulamak için bir "toplu alıcı" mantıksal uygulama iş akışı ve "toplu gönderen" 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, abonelik zamanında gerçekleşen ve hedefin tetikleyiciyi veya eylemi yalnızca bir olay gerçekleştiğinde bildirimde bulunmasını isteyen hedef hizmete veya sisteme yalnızca tek bir çağrı oluşturur. 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.