Azure İşlevleri'nin performansını ve güvenilirliğini geliştirme

Bu makalede sunucusuz işlev uygulamalarınızın performansını ve güvenilirliğini artırmaya yönelik yönergeler sağlanmaktadır. Daha genel bir Azure İşlevleri en iyi yöntemleri kümesi için bkz. Azure İşlevleri en iyi yöntemleri.

Aşağıda, Azure İşlevleri'ni kullanarak sunucusuz çözümlerinizi oluşturma ve tasarlama konusunda en iyi yöntemler yer alır.

Uzun süre çalışan işlevlerden kaçının

Büyük ve uzun süre çalışan işlevler beklenmeyen zaman aşımı sorunlarına neden olabilir. Belirli bir barındırma planının zaman aşımları hakkında daha fazla bilgi edinmek için bkz. işlev uygulaması zaman aşımı süresi.

birçok Node.js bağımlılığı nedeniyle bir işlev büyük olabilir. Bağımlılıkların içeri aktarılması, beklenmeyen zaman aşımlarına neden olan yükleme sürelerinin artmasına da neden olabilir. Bağımlılıklar hem açıkça hem de örtük olarak yüklenir. Kodunuz tarafından yüklenen tek bir modül kendi ek modüllerini yükleyebilir.

Mümkün olduğunda, büyük işlevleri birlikte çalışan ve yanıtları hızlı bir şekilde döndüren daha küçük işlev kümeleri halinde yeniden düzenleme. Örneğin, bir web kancası veya HTTP tetikleyici işlevi belirli bir süre içinde bildirim yanıtı gerektirebilir; Web kancalarının hemen yanıt gerektirmesi yaygın bir durum. HTTP tetikleyici yükünü, bir kuyruk tetikleyici işleviyle işlenecek olan kuyruğa aktarabilirsiniz. Bu yaklaşım gerçek çalışmayı ertelemenize ve anında yanıt döndürmenize olanak tanır.

Arka plan görevlerinin tamamlandığından emin olun

İşleviniz herhangi bir görevi, geri çağırmayı, iş parçacığını, işlemi başlattığında, işlev kodunuz döndürülmeden önce bunların tamamlanması gerekir. İşlevler bu arka plan iş parçacıklarını izlemediğinden, arka plan iş parçacığı durumundan bağımsız olarak site kapatma işlemi gerçekleşebilir ve bu da işlevlerinizde istenmeyen davranışlara neden olabilir.

Örneğin, bir işlev bir arka plan görevi başlatır ve görev tamamlanmadan önce başarılı bir yanıt döndürürse, İşlevler çalışma zamanı arka plan görevinin sonucundan bağımsız olarak yürütmeyi başarıyla tamamlamış olarak kabul eder. Bu arka plan görevi kritik işleri gerçekleştiriyorsa, site kapatma işlemiyle durdurulabilir ve çalışmalar bilinmeyen bir duruma bırakılabilir.

İşlevler arası iletişim

Dayanıklı İşlevler ve Azure Logic Apps , durum geçişlerini ve birden çok işlev arasındaki iletişimi yönetmek için oluşturulur.

Birden çok işlevle tümleştirmek için Dayanıklı İşlevler veya Logic Apps kullanmıyorsanız, işlevler arası iletişim için depolama kuyruklarını kullanmak en iyisidir. Bunun temel nedeni, depolama kuyruklarının diğer depolama seçeneklerine göre daha ucuz ve sağlanması çok daha kolay olmasıdır.

Depolama kuyruğundaki tek tek iletilerin boyutu 64 KB ile sınırlıdır. İşlevler arasında daha büyük iletiler geçirmeniz gerekiyorsa, Standart katmanda 256 KB'a ve Premium katmanında 100 MB'a kadar ileti boyutlarını desteklemek için bir Azure Service Bus kuyruğu kullanılabilir.

İşlemeden önce ileti filtrelemeye ihtiyacınız varsa Service Bus konuları kullanışlıdır.

Olay hub'ları yüksek hacimli iletişimleri desteklemek için kullanışlıdır.

İşlevleri durumsuz olacak şekilde yazın

İşlevler, mümkünse, durumsuz ve idempotent olmalıdır. Gerekli durum bilgilerini verilerinizle ilişkilendirin. Örneğin, işlenen bir siparişin büyük olasılıkla ilişkili state bir üyesi olabilir. İşlevin kendisi durum bilgisi taşımadığı halde, duruma göre bir siparişi işleyebilir.

Idempotent işlevleri özellikle zamanlayıcı tetikleyicileri ile önerilir. Örneğin, mutlaka günde bir kez çalıştırılması gereken bir şey varsa, aynı sonuçlarla gün içinde her zaman çalışabilmesi için bunu yazın. Belirli bir gün için iş olmadığında işlev sonlandırılabilir. Ayrıca önceki bir çalıştırma tamamlanamadıysa, sonraki çalıştırmanın kaldığı yerden devam etmesi gerekir. Bu, hata durumunda yeniden deneyen ileti tabanlı bağlamalar için özellikle önemlidir. Daha fazla bilgi için bkz. Aynı giriş için Azure İşlevleri tasarlama.

Koruyucu fonksiyonlar yazın

İşlevinizin herhangi bir zamanda bir özel durumla karşılaşabileceğini varsayalım. İşlevlerinizi, sonraki yürütme sırasında önceki bir hata noktasından devam etme özelliğiyle tasarlayın. Aşağıdaki eylemleri gerektiren bir senaryo düşünün:

Veritabanında 10.000 satır için sorgu yapın.
Bu satırların her biri için bir kuyruk mesajı oluşturun ve sıradaki işlemlere hazır hale getirin.

Sisteminizin ne kadar karmaşık olduğuna bağlı olarak, aşağı akış hizmetlerinin kötü davranmasına, ağ kesintilerine veya kota sınırlarına ulaşılması vb. dahil olmuş olabilirsiniz. Bunların tümü istediğiniz zaman işlevinizi etkileyebilir. İşlevlerinizi buna hazırlıklı olacak şekilde tasarlamanız gerekir.

Bu öğelerin 5.000'i işlenmek üzere kuyruğa eklendikten sonra bir hata oluştuğunda kodunuz nasıl tepki gösteriyor? Tamamladığınız bir kümedeki öğeleri izleyin. Aksi takdirde, bunları bir dahaki sefere yeniden ekleyebilirsiniz. Bu çift ekleme, iş akışınızı ciddi şekilde etkileyebilir, bu yüzden işlevlerinizi idemputent hale getirin.

Bir kuyruk öğesi zaten işlendiyse, işlevinizin herhangi bir işlem yapmamasına izin verin.

Azure İşlevleri platformunda kullandığınız bileşenler için önceden sağlanan savunma önlemlerinden yararlanın. Örneğin, Azure Depolama Kuyruğu tetikleyicileri ve bağlamaları belgelerinde zehirli kuyruk iletilerini işleme bölümüne bakın.

HTTP tabanlı işlevler için Azure API Management ile API sürüm oluşturma stratejilerini göz önünde bulundurun. Örneğin, HTTP tabanlı işlev uygulamanızı güncelleştirmeniz gerekiyorsa, yeni güncelleştirmeyi ayrı bir işlev uygulamasına dağıtın ve istemcileri yeni sürüme veya düzeltmeye yönlendirmek için API Management düzeltmelerini veya sürümlerini kullanın. Tüm istemciler yeni sürüm veya revizyonu kullandığında ve önceki işlev uygulaması üzerinde başka yürütme kalmadığında, önceki işlev uygulamasının devre dışı bırakılması işlemini gerçekleştirebilirsiniz.

İşlev kuruluşu en iyi yöntemleri

Çözümünüzün bir parçası olarak birden çok işlev geliştirebilir ve yayımlayabilirsiniz. Bu işlevler genellikle tek bir işlev uygulamasında birleştirilir, ancak ayrı işlev uygulamalarında da çalıştırılabilir. Premium ve ayrılmış (App Service) barındırma planlarında, birden çok işlev uygulaması aynı planda çalıştırarak aynı kaynakları paylaşabilir. İşlevlerinizi ve işlev uygulamalarınızı gruplandırma şekliniz genel çözümünüzün performansını, ölçeklendirmesini, yapılandırmasını, dağıtımını ve güvenliğini etkileyebilir. Her senaryo için geçerli kural yoktur, bu nedenle işlevlerinizi planlarken ve geliştirirken bu bölümdeki bilgileri göz önünde bulundurun.

Performans ve ölçeklendirme için işlevleri düzenleme

Oluşturduğunuz her işlevin bir bellek ayak izi vardır. Bu ayak izi genellikle küçük olsa da, bir işlev uygulamasında çok fazla işlev olması uygulamanızın yeni örneklerde daha yavaş başlatılmasına neden olabilir. Ayrıca işlev uygulamanızın genel bellek kullanımının daha yüksek olabileceği anlamına da gelir. Tek bir uygulamada kaç işlevin olması gerektiğini söylemek zordur ve bu da belirli iş yükünüze bağlıdır. Ancak, işleviniz bellekte çok fazla veri depolarsa, tek bir uygulamada daha az işlev olmasını göz önünde bulundurun.

Tek bir Premium plan veya ayrılmış (App Service) planında birden çok işlev uygulaması çalıştırıyorsanız, bu uygulamaların tümü plana ayrılan kaynakları paylaşır. Bellek gereksinimi diğerlerinden çok daha yüksek olan bir işlev uygulamanız varsa, uygulamanın dağıtıldığı her örnekte orantısız miktarda bellek kaynağı kullanır. Bu, her örnekteki diğer uygulamalar için daha az kullanılabilir bellek bırakabileceğinden, bunun gibi yüksek bellek kullanan bir işlev uygulamasını kendi ayrı barındırma planında çalıştırmak isteyebilirsiniz.

Uyarı

Tüketim planını kullanırken, uygulamalar yine de bağımsız olarak ölçeklendirildiğinden her uygulamayı her zaman kendi planına yerleştirmenizi öneririz. Daha fazla bilgi için bkz . Aynı planda birden çok uygulama.

İşlevleri farklı yük profilleriyle gruplandırmak isteyip istemediğinizi düşünün. Örneğin, binlerce kuyruk iletisini işleyen bir işleviniz ve yalnızca ara sıra çağrılan ancak yüksek bellek gereksinimleri olan bir işleviniz varsa, kendi kaynak kümelerini almaları ve birbirinden bağımsız olarak ölçeklendirilmeleri için bunları ayrı işlev uygulamalarına dağıtmak isteyebilirsiniz.

Yapılandırma ve dağıtım için işlevleri düzenleme

İşlev uygulamaları, işlev tetikleyicilerinin ve Azure İşlevleri çalışma zamanının gelişmiş davranışını yapılandırmak için kullanılan bir host.json dosyaya sahiptir. Dosyada yapılan host.json değişiklikler uygulama içindeki tüm işlevlere uygulanır. Özel yapılandırmalara ihtiyaç duyan bazı işlevleriniz varsa bunları kendi işlev uygulamalarına taşımayı göz önünde bulundurun.

Yerel projenizdeki tüm işlevler, Azure'daki işlev uygulamanıza bir dizi dosya olarak birlikte dağıtılır. Belirli işlevleri ayrı ayrı dağıtmanız veya bazı işlevler için dağıtım yuvaları gibi özellikleri kullanırken diğerleri için kullanmamanız gerekebilir. Böyle durumlarda, bu işlevleri (ayrı kod projelerinde) farklı işlev uygulamalarına dağıtmanız gerekir.

İşlevleri ayrıcalıklara göre düzenle

Uygulama ayarlarında depolanan bağlantı dizeleri ve diğer kimlik bilgileri, işlev uygulamasındaki tüm işlevlere ilişkili kaynakta aynı izin kümesini verir. Bu kimlik bilgilerini kullanmayan işlevleri ayrı bir işlev uygulamasına taşıyarak belirli kimlik bilgilerine erişimi olan işlev sayısını en aza indirmeyi göz önünde bulundurun. Farklı işlev uygulamalarındaki işlevler arasında veri geçirmek için her zaman işlev zinciri gibi teknikleri kullanabilirsiniz.

Ölçeklenebilirlik için en iyi yöntemler

İşlev uygulamanızın örneklerinin ölçeğini etkileyen çeşitli faktörler vardır. Ayrıntılar , işlev ölçeklendirme belgelerinde verilmiştir. Aşağıda, bir işlev uygulamasının en iyi ölçeklenebilirliğini sağlamaya yönelik en iyi uygulamalardan bazıları yer alır.

Mümkün olduğunda dış kaynaklara bağlantıları yeniden kullanın. Bkz. Azure İşlevleri'nde bağlantıları yönetme.

bir işlev uygulaması oluşturduğunuzda, bunu bir depolama hesabıyla ilişkilendirmeniz gerekir. Depolama hesabı bağlantısı AzureWebJobsStorage uygulama ayarında korunur.

Performansı en üst düzeye çıkarmak için her işlev uygulaması için ayrı bir depolama hesabı kullanın. Bu yaklaşım özellikle Dayanıklı İşlevler veya Event Hubs ile tetiklenen ve her ikisi de yüksek hacimli depolama işlemleri oluşturan işlevlere sahip olduğunuzda önemlidir. Uygulama mantığınız Azure Depolama ile doğrudan (Depolama SDK'sını kullanarak) veya depolama bağlamalarından biri aracılığıyla etkileşime geçtiğinde, ayrılmış bir depolama hesabı kullanmanız gerekir. Örneğin, olay hub tetikleyicisi ile veri yazan bir işleviniz varsa, biri işlev uygulaması için, diğeri işlevin depolediği bloblar için olmak üzere iki ayrı depolama hesabı kullanın.

Test ve üretim kodunu aynı işlev uygulamasında karıştırmayın

İşlev uygulamasındaki işlevler kaynakları paylaşır. Örneğin, bellek paylaşılır. Üretimde bir işlev uygulaması kullanıyorsanız testle ilgili işlevleri ve kaynakları buna eklemeyin. Üretim kodu yürütme sırasında beklenmeyen ek yüke neden olabilir.

Üretim işlevi uygulamalarınıza yüklerken dikkatli olun. Bellek, uygulamadaki her işlev için ortalama olarak alınır.

Birden çok .NET işlevinde başvurulan bir paylaşılan derlemeniz varsa, bunu ortak bir paylaşılan klasöre yerleştirin. Aksi takdirde, işlevler arasında farklı davranan aynı ikili dosyanın birden çok sürümünü yanlışlıkla dağıtabilirsiniz.

Olumsuz performans etkisi olan üretim kodunda ayrıntılı günlük kaydı kullanmayın.

Zaman uyumsuz kod kullanın ancak çağrıları engellemekten kaçının

Zaman uyumsuz programlama, özellikle bloklayan G/Ç işlemleri söz konusu olduğunda önerilen en iyi yöntemdir.

C# dilinde her zaman bir Result örneğinde Wait özelliğine başvurmaktan veya Task yöntemini çağırmaktan kaçının. Bu yaklaşım iş parçacığı tükenmesine neden olabilir.

Tavsiye

HTTP veya Web Kancası bağlamalarını kullanmayı planlıyorsanız, yanlış örnek oluşturmanın neden olabileceği bağlantı noktası tükenmesini önlemeyi planlayın HttpClient. Daha fazla bilgi için bkz. Azure İşlevleri'da bağlantıları yönetme.

Birden çok çalışan işlemleri kullanın

Varsayılan olarak, İşlevler için herhangi bir konak örneği, tek bir çalışan işlemi kullanır. Özellikle Python gibi tek iş parçacıklı çalışma zamanlarında performansı artırmak için FUNCTIONS_WORKER_PROCESS_COUNT kullanarak konak başına çalışan işlemlerinin sayısını artırın (10'a kadar). Azure İşlevleri daha sonra eş zamanlı işlev çağrılarını bu çalışanlara eşit olarak dağıtmaya çalışır.

FUNCTIONS_WORKER_PROCESS_COUNT, talebi karşılamak için uygulamanızın ölçeği genişletilirken İşlevler tarafından oluşturulan her konağa uygulanır.

Mümkün olduğunda iletileri toplu olarak alın

Olay Hub'ı gibi bazı tetikleyiciler tek bir çağrıda toplu ileti almayı etkinleştirir. Mesajları toplu işlemek çok daha iyi performans gösterir. Dosyadaki host.json en büyük toplu iş boyutunu host.json başvuru belgelerinde açıklandığı gibi yapılandırabilirsiniz

C# işlevleri için türü kesin olarak belirlenmiş bir dizi olarak değiştirebilirsiniz. Örneğin, yöntem imzası yerine EventData sensorEvent olabilir EventData[] sensorEvent. Diğer diller için, burada function.json toplu işlemi etkinleştirmek amacıyla many içindeki kardinalite özelliğini olarak açıkça ayarlamanız gerekir.

Eşzamanlılığı daha iyi işlemek için konak davranışlarını yapılandırma

host.json İşlev uygulamasındaki dosya, konak çalışma zamanının yapılandırılmasına ve tetikleyici davranışlarına olanak tanır. Toplu işleme davranışlarına ek olarak, bir dizi tetikleyici için eşzamanlılığı yönetebilirsiniz. Bu seçeneklerdeki değerlerin ayarlanması genellikle her örneğin çağrılan işlevlerin talepleri için uygun şekilde ölçeklendirilmesine yardımcı olabilir.

host.json dosyasındaki ayarlar, işlevin tek bir örneğindeki uygulamadaki tüm işlevlere uygulanır. Örneğin, iki HTTP işlevi ve maxConcurrentRequests isteği 25 olarak ayarlanmış bir işlev uygulamanız varsa, HTTP tetikleyicilerinden herhangi biri için bir istek paylaşılan 25 eşzamanlı istek için sayılır. Bu işlev uygulaması 10 örneğe ölçeklendirildiğinde, on işlev etkin bir şekilde 250 eşzamanlı isteğe (örnek başına 10 örnek * 25 eşzamanlı istek) izin verir.

Sunucu yapılandırma seçeneklerinin diğerleri host.json yapılandırma makalesinde bulunur.

Sonraki Adımlar

Daha fazla bilgi için aşağıdaki kaynaklara bakın:

Geri Bildirim

Bu sayfayı yararlı buldunuz mu?

Last updated on 2025-07-22