Power Automate Akışları için Performans Ayarlama

Aslında saniyeler içinde tamamlanabilecek bir görev için dakikalarca süren bir Power Automate akışı sadece zaman kaybettirmez. Planınızın sınırlı eylem taleplerinin gereksiz yere büyük bir kısmını tüketir, alt sistemlerde zaman aşımı hatalarını artırır ve her çalıştırmada daha fazla adımdan geçilmesi gerektiği için hata ayıklamayı zorlaştırır. İyi haber şu: Power Automate'teki performans sorunlarının çoğu, Microsoft'un kendi kodlama yönergelerinde ayrıntılı olarak belgelediği üç ana etkene indirgenebilir. Güncelleme: Temmuz 2026.

Bu yazı, Microsoft'un Power Automate için resmi belgelerine dayanarak, hedefli paralellik, gereksiz eylemlerin azaltılması ve doğru bağlayıcı (connector) ile veri seçimiyle nasıl belirgin şekilde daha hızlı akışlar oluşturabileceğinizi özetliyor. Böylece, neredeyse hiçbir şeyi değiştirmeyen ayarlarla rastgele oynamak yerine, hangi etkenin kendi akışınız için en büyük etkiyi yarattığı konusunda kontrolü elinizde tutarsınız.

Akışlar neden yavaşlar

Optimize etmeden önce nedenine bakmakta fayda var. Performans sorunlarını teşhis etme kılavuzuna göre, yavaşlayan birçok akış basitçe günlük Power Automate limitlerine ulaşıyor. "Akışlarım" bölümündeki eylem analizi, bir akışın gerçekte kaç eylem talebi tükettiğini gösterir ve bir akış eylem limitlerini tekrar tekrar aşarsa Power Automate sahiplerini e-posta ile bile bilgilendirir. Aynı derecede önemli olan: bağlı hizmetlerin kendileri de koruma limitleri uygular ve bunlar akışınızda 429 hatası (çok fazla istek) veya 5xx hatası (zaman aşımı) olarak görünür. Bu limitler bağlayıcıya ve hizmete göre farklılık gösterir, bu yüzden aynı akış mantığı SharePoint'te Dataverse'e veya harici bir API'ye göre çok farklı performans gösterebilir.

Etken 1: Paralelliği hedefli kullanmak

Bağımsız adımlar için paralel dallar

Şu kılavuza göre: Paralel yürütme ve paralellik, iki veya daha fazla eylem birbirine bağımlı olmadığında ve her biri beş saniyeden uzun sürdüğünde paralel dallar işe yarar. Microsoft'a göre tipik kullanım örnekleri, engellemeyen onay talepleri, kotaya (quorum) dayalı onay süreçleri, birden fazla sistemde kayıtların aynı anda oluşturulması veya güncellenmesi ile birden fazla değişkenin paralel olarak başlatılmasıdır.

Her Öğeye Uygula döngülerinde eşzamanlılık denetimi

Bu etki döngülerde daha da belirgin hale gelir. Varsayılan olarak bir Her Öğeye Uygula döngüsü sıralı olarak, öğe öğe çalışır. Belgeler, dört girişlik bir test dizisi üzerinden bunun paralellik sayesinde ne kadar kısaldığını gösteriyor:

• Paralellik devre dışı: 21 saniye
• Paralellik derecesi 2: 11 saniye
• Paralellik derecesi 4: 6 saniye
• Paralellik derecesi 6: 6 saniye

Paralellik derecesini 1 ile 50 arasında ayarlayabilirsiniz. Önemli olan şu: yüksek bir sayı her şeyi otomatik olarak hızlandırmaz, çünkü işi bölmek, ek iş parçacıklarını (thread) sıraya koymak ve çağrılan uç noktadan kaynaklanan gecikmeler kendi başlarına ek yük oluşturur. Ayrıca iç içe geçmiş Her Öğeye Uygula döngüleri her zaman sıralı olarak çalışır; Microsoft'a göre paralellik ayarı yalnızca bulut akışının en üst düzeyinde etkilidir.

Tetikleyici paralelliği: yalnızca dikkatli kullanın

Tetikleyici düzeyinde ayrıca varsayılan olarak kapalı olan bir eşzamanlılık denetimi etkinleştirilebilir; bu ayar bir akışın aynı anda kaç örneğinin çalışabileceğini belirler. Sınırlı işlem hacmine sahip veri kaynaklarında yardımcı olur ve paralel bir çalıştırmanın kaydı bu sırada değiştirmesi nedeniyle bir akışın eski verilerle çalışmaya devam ettiği sözde kirli okumaları (dirty reads) önler. Ancak Microsoft açıkça dikkatli olunmasını tavsiye eder: bu ayar etkinleştirildikten sonra geri alınamaz, yalnızca tetikleyicinin yeniden oluşturulmasıyla değiştirilebilir. En iyi uygulama olarak belgeler, eşzamanlılık denetiminin tüm ana akışı değil, mümkün olduğunca az eylem içeren özel bir alt akışa uygulanmasını önerir.

Etken 2: Gereksiz eylemleri ve döngüleri azaltmak

İç içe döngülerden kaçınmak

Bulut akışlarındaki anti-kalıplar kılavuzu, iç içe geçmiş Her Öğeye Uygula döngülerini en maliyetli tuzaklardan biri olarak nitelendiriyor. Her biri on yinelemeli iki döngü matematiksel olarak 100 çalıştırma anlamına gelir; daha büyük veri hacimlerinde bu sayı katlanarak artar ve hızla yineleme ile toplam yürütme süresi limitlerine ulaşır. Belgelenen alternatif: ilişkili kayıtları ikinci, iç içe bir döngüde yeniden yüklemek yerine, bunları tek bir sorguda birlikte yüklemek için OData sorgu genişletmesini kullanmak. `Products($select=ProductName,Price)` gibi bir parametre, tüm iç döngünün yerini Dataverse'e yapılan tek bir ek RetrieveMultiple çağrısıyla alır.

Sonradan yapılan kontroller yerine tetikleyici koşulları

Birçok akış, çalıştırmaların yalnızca küçük bir kısmı gerçekten anlamlı olsa bile, bir veri kaynağındaki her değişiklikte başlar. Doğrudan tetikleyicide kontrol edilen bir tetikleyici koşulu, bu gereksiz çalıştırmaları akış başladıktan sonra dahili bir koşulla yakalamak yerine, en baştan önler. Bu, yalnızca zamandan değil, aksi takdirde her ilgisiz çalıştırmada tüketilecek eylem taleplerinden de tasarruf sağlar.

Tek tek eylemler yerine toplu ve kitlesel işlemler

Belgelere göre, yüzlerce veya binlerce kayıt oluşturması ya da güncellemesi gerekenlerin her kaydı tek tek bir For each döngüsünde işlememesi gerekir. Toplu işlemler birden fazla isteği tek bir HTTP isteğinde birleştirirken, Dataverse'teki kitlesel işlem web API'leri bir adım daha ileri gider: çok sayıda tek tek "Satır oluştur" eylemi yerine, 100 hazırlanmış kayıtla yapılan tek bir CreateMultiple web API çağrısı yalnızca tek bir eylem olarak sayılır.

Etken 3: Bağlayıcı seçimi ve veri hacmini sınırlamak

Yalnızca gerçekten ihtiyacınız olan verileri yükleyin

Şu kılavuza göre: Yalnızca ilgili verilerle çalışın, işlenen veri hacmi hem tetikleyicide hem de tek tek eylemlerde sınırlandırılabilir. Dataverse kaynaklarında Sütunları seç, Satırları filtrele ve Satır sayısı parametreleri sonuç kümesini doğrudan kaynakta azaltır. SharePoint'te ise Filtre sorgusu, En yüksek sayı ve Görünüme göre sütunları sınırla aynı amaca hizmet eder. Bu önemlidir, çünkü sözde işlem hacmi limitleri (throughput limits), bir bulut akışının belirli bir süre içinde çalıştırma geçmişinden ne kadar veri hacmi okuyup yazabileceğini sınırlar. Bu limit 14 gün boyunca sürekli aşılırsa, Power Automate akışı otomatik olarak devre dışı bırakır.

En kolay eylem yerine doğru eylem

Bağlayıcı seçimi aynı zamanda, aynı görev için otomatik olarak en maliyetli eyleme başvurmamak anlamına da gelir. Örneğin Filter array, Select veya Join gibi veri işlemleri dizileri doğrudan işler ve sonraki adımlardan geçen veri hacmini, genellikle koşullu ek bir döngüden çok daha verimli bir şekilde azaltır. Bir hizmet, bağlayıcının kendisinde yerel filtreleme veya seçim parametreleri sunuyorsa, Microsoft belgelerine göre tüm veri hacmini önce akışa yükleyip ardından ayrı bir veri işlemiyle azaltmak yerine, orada filtrelemek daha verimlidir.

Kendi akışınızdaki darboğazı nasıl bulursunuz

Gerçek nedeni bulmanın en hızlı yolu sabit bir kontrol sırası izlemektir. Öncelikle etkilenen akışın eylem analizini açın ve günlük limitlerine ne kadar yaklaştığını kontrol edin. Ardından çalıştırma geçmişinde dikkat çekici derecede uzun süren tek tek eylemler olup olmadığını kontrol edin; bunlar genellikle paralelliği olmayan döngüler veya gereksiz yere büyük veri hacimleri yükleyen eylemlerdir. Ayrıca 429 veya 5xx türünde hatalar olup olmadığını kontrol edin; bunlar Power Automate'in kendisinden değil, bağlı bir hizmetin limitlerinden kaynaklanır. Birden fazla ortamı olan daha kapsamlı akış yapılarında genellikle yapılandırılmış bir Power Automate danışmanlığı işe yarar; bu danışmanlık her akışı tek tek optimize etmek yerine, tüm kritik akışlar için paralelliği, veri hacmini ve bağlayıcı seçimini sistematik olarak ele alır.

Sık sorulan sorular

Bir Her Öğeye Uygula döngüsünde paralel olarak kaç öğe işlemeliyim?

Genel geçer bir en iyi değer yoktur; Microsoft, paralellik derecesinin 1 ile 50 arasında olmasına izin verir. Dört öğeyle yapılan belgelenmiş örnek ölçümde, paralellik değeri 4 zaten maksimum hızlanmayı sağlamış, değerin 6'ya çıkarılması çalıştırma süresinde artık bir değişiklik yaratmamıştır. Uygulamada, doğrudan maksimum değeri ayarlamak yerine 5 ile 10 arasında ölçülü bir değerle başlamak ve çalıştırma süresini çalıştırma geçmişinde izlemek işe yarar, çünkü çok yüksek paralellik, çağrılan uç noktadan kaynaklanan gecikmelere kendisi de yol açabilir.

Tetikleyici eşzamanlılık denetimi performansı otomatik olarak artırır mı?

Otomatik olarak artırmaz ve Microsoft aslında temkinli olunmasını tavsiye eder. Eşzamanlılık denetimi olmadan varsayılan ayar, sistemin işleyebileceği kadar çok eşzamanlı çalıştırmaya izin verir ve bu, çoğu senaryo için zaten yeterince performanslıdır. Eşzamanlılık denetimi, genel bir hızlandırma önlemi olarak değil, öncelikle bağlı bir kaynağın yalnızca sınırlı bir işlem hacmini kaldırabildiği veya kirli okumaların (dirty reads) önlenmesi gerektiği durumlarda anlamlıdır. Bu ayar geri alınamadığından, yalnızca küçük, özel bir akışa hedefli olarak uygulamalısınız.

İç içe döngüler neden bu kadar büyük bir performans sorunu oluşturur?

Çünkü çalıştırma sayısı toplanmak yerine çarpılır. Her biri on öğe içeren, birbirinin içine yerleştirilmiş iki döngü 100 ayrı çalıştırmaya yol açar; daha büyük veri hacimlerinde bu sayı katlanarak artmaya devam eder. Bu yalnızca zaman kaybettirmekle kalmaz, aynı zamanda akışı hızla yineleme ve toplam yürütme süresi limitlerine yaklaştırır; bu da en kötü durumda akış hatalarına veya kısıtlamaya (throttling) yol açar.

Birden fazla bağlayıcı aynı görevi yerine getirebiliyorsa, bağlayıcı seçiminin performansla ne ilgisi vardır?

Bağlayıcılar genellikle doğrudan veri kaynağında farklı ayrıntı düzeylerinde filtreleme ve seçim parametreleri sunar. Tetikleyicide veya eylemde zaten filtreleme, sütun seçimi ve maksimum satır sayısını destekleyen bir bağlayıcı, işlenen veri hacmini daha akışa ulaşmadan önce azaltır. Bu, işlem hacmi limitlerini doğrudan etkiler ve bir akışın çok yüksek veri hacmi nedeniyle kısıtlanma veya uzun süreli aşım sonrasında otomatik olarak devre dışı bırakılma riskini azaltır.

Yavaş bir akışın Power Automate'ten mi yoksa bağlı hizmetten mi kaynaklandığını nasıl anlarım?

Çalıştırma geçmişindeki hata kodlarına bakmak cevabı verir. 429 türü hatalar veya 5xx aralığındaki zaman aşımları, bağlayıcıya göre farklılık gösteren, bağlı hizmetin koruma limitlerine işaret eder. Buna karşılık Power Automate'in kendisi günlük eylem taleplerine ulaşırsa, bu durum "Akışlarım" bölümündeki eylem analizinde açıkça görünür ve sahipler ayrıca eylem sayısını azaltmaya yönelik ipuçları içeren otomatik bir bildirim alır.