Azure App Service üzərində host edilən veb tətbiqin cavabvermə müddəti artıb, səhifələr yüklənməkdə ləngiyir və ya vaxtaşırı time-out xətaları müşahidə olunur. İstifadəçilər performansın kəskin düşdüyünü bildirə bilər. Tipik simptomlar: – Sorğuların cavabvermə vaxtı yüksəkdir, bəzi sorğular 30+ saniyə çəkir və bəzən vaxt aşımına uğrayır. – Tətbiqin yük altında olduğunda resurs istifadəsi (CPU, RAM) demək olar tam dolur, ancaq avtomatik scale-out (üfiqi ölçü artımı) baş vermir və ya yetərli olmur. – Deploy-dan və ya uzun müddət işsizlikdən sonra ilk sorğuların cavabında xüsusi gecikmə (bir neçə saniyəlik soyuq start gecikməsi) hiss olunur. – Tətbiqin asılı olduğu xarici servislər (məsələn, database, API) yavaş işləyir; dependency çağırışları səbəbindən ümumi işləmə sürəti aşağı düşür.
Mümkün kök səbəblər:
- Resurs yetərsizliyi / ölçüləndirmənin olmaması: Tətbiqin trafik həcmi və yükü mövcud instance sayını və ya servis planının gücünü aşır. Nəticədə CPU və ya RAM tavan həddə çatır, sorğular növbəyə düşür və gecikmələr yaranır. Avtomatik ölçeklendirme (autoscale) tənzimlənməyibsə və ya limitə çatıbsa, əlavə instanslar yaranmır, performans pisləşir.
- Soyuq start: Xüsusilə Always On deaktivdirsə və tətbiq uzun müddət heç bir trafik almayıbsa, host prosesi yuxuya keçir. İlk sorğuda tətbiq yenidən yüklənir ki, bu da bir neçə saniyə əlavə gecikmə yarada bilər. Consumption planlı Azure Functions-lər və ya aşağı səviyyəli App Service planları soyuq startdan əziyyət çəkir. Always On funksiyası qapalıdırsa, soyuq start bir neçə saniyədən bir neçə dəqiqəyədək gecikmə yaradaraq ilk istifadə təcrübəsini pozur.
- Asılılıq (dependency) tıxanmaları: Tətbiq bir və ya bir neçə xarici xidmətə (məsələn, SQL DB, Redis, üçüncü tərəf API) çağırışlar edir və həmin çağırışlar ləngiyir. Belə olduqda, istifadəçi sorğusu həmin asılılığın cavabını gözlədiyi üçün yubanır. Məsələn, verilənlər bazasında optimallaşmamış bir sorğu və ya kilidlənmə (deadlock) tətbiqin veb sorğularını ləngidə bilər. Application Insights tez-tez göstərir ki, yavaş sorğuların əsas səbəbi bir xarici dependency çağırışının yubanmasıdır.
- Tətbiq səviyyəsində səhvlər və ya sızmalar: Sonsuz dövr (loop) kimi yüksək CPU istehlak edən kod, yaddaş sızması (memory leak) kimi RAM-i tədricən dolduran problemlər performansı azalda bilər. Bu cür kod defektləri az yükdə hiss olunmaya bilər, lakin trafik artdıqda performansı kəskin pisləşdirər.
- Ölçüləndirmə limitləri: Bəzən App Service planının limitlərinə çatılır – məsələn, eyni anda çox sayda Thread açılır və ya Connections limitini aşır. Və ya .NET thread pool limitlərinə görə sorğular gecikir. Yüksək yük zamanı autoscale tənzimlənibsə belə, yeni instans yaranana qədər performans düşə bilər.
Diaqnostika üsulları:
İlk addım kimi Azure Monitor və Application Insights vasitələri ilə tətbiqin davranışını müşahidə edin. Azure Portalda App Service üçün Metrics bölməsinə daxil olaraq vacib metrikləri izləyin: CPU faizi, Memory Working Set, Http Queue Length, Requests və Average Response Time kimi. Məsələn, orta cavab müddəti kəskin artır, eyni zamanda CPU da 80-100% aralığında davamlı qalırsa, bu, resurs əskikliyinə işarədir. Http Queue Length metri olduğu halda (App Service-in gözləmə növbəsindəki sorğuların sayı), bu göstərici artıbsa (məs., 0-dan böyükdürsə), deməli, instans sorğulara vaxtında cavab verə bilmir – ölçünü artırmaq (scale-out) lazım gələ bilər.
Application Insights varsa, Performance bölməsində ən yavaş sorğu növlərini və onların orta/percentile cavab müddətlərini təhlil edin. Oradan konkret yavaş istəkləri seçib End-to-End Transaction Details baxışı ilə onların içindəki Dependency çağırışlarını araşdırmaq olar. Bu vasitə göstərir ki, əgər bir HTTP request yavaşdırsa, bunun səbəbi həmin sorğu daxilində baş verən hansısa asılı xidmət çağırışının ləng cavab verməsidir, yoxsa problem birbaş kodun içindədir. Məsələn, Application Insights-ın Transaction timeline grafikində görmək olar ki, yavaşıdıran hissə bir SQL query və ya xarici HTTP çağırışıdır – bu halda həmin xətt qrafikdə uzun yer tutur. Əgər çoxlu sayda yavaş sorğu eyni asılı servisin (məsələn, eyni API endpoint-in) çağırışı zamanı baş verirsə, deməli, həmin servis boyun boğazı (bottleneck) yaradır.
App Service Diagnostics və Diagnose and Solve Problems bıçağından da yararlanın. Azure Portalda App Service resursunun bu bölməsi ümumi performans problemlərini avtomatik analiz edib təkliflər verir. Burada “High CPU Analysis” və ya “Slow Response Time” kimi tövsiyələr çıxa bilər. Həmçinin, Profiler (Application Insights Profiler) aktivdirsə, zaman-zaman kodun profilini toplayır. Profiler izləmələrini (“trace”) Application Insights-da Profiler bölməsində analiz etmək olar – o, yavaş sorğularda ən çox vaxt aparan kod sətirlərini göstərir. Məsələn, Profiler nəticəsində görünə bilər ki, yavaş sorğuların 80%-i müəyyən bir funksiyada uzun müddət gözləyir (məsələn, await olan bir xarici çağırış). Bu məlumatlar kod səviyyəsində optimallaşdırma istiqamətini müəyyən edir.
Loglar və jurnalların təhlili: App Service-də Application Logging (və gerekiyorsa Web Server Logging) aktiv edilibsə, loglarda istisnalar (exception) və ya səhv izahları görmək olar. Xüsusən, “OutOfMemory” və ya “TimeoutException” kimi səhvlər görünürsə, problem kod yaxud asılı servislərdədir. Failed Request Tracing (düzgün konfiqurasiya edilərsə) konkret HTTP 500 səhvlərinin trace fayllarını təqdim edib, harada çox vaxt sərf olunduğunu göstərə bilər. Bundan əlavə, Azure Monitor Application Insights – Live Metrics Stream ilə real zamanda sorğu sayı, gecikmə və səhv faizini izləyə bilərsiniz.
Scale-out monitorinqi: Avtomatik ölçüləndirmə (autoscale) konfiqurasiya edilibsə, Activity Log-da autoscale hadisələrinə baxın – məsələn, son bir saatda instans sayının artıb-azalması qeydə alınıbmı? Əgər autoscale qurulubsa lakin baş vermirsə, autoscale qaydalarının şərtlərini yenidən gözdən keçirin (bəlkə tətik olma həddi çox yüksək qoyulub). App Service planının Scale out bölümündə mövcud instance sayını və limitini də yoxlayın (bəzən istifadəçi maksimum instance sayını 1 olaraq saxlayır, autoscale olsa belə 1-dən yuxarı çıxmır).
Sınaqdan keçmiş həllər:
- Scale-out (üfiqi genişləndirmə): Əgər diaqnostika resurs sıxlığını (CPU, RAM) göstərirsə və mövcud planınız artıq dolubsa, tətbiqi daha çox instance üzərində çalışdırmaq tələb olunur. Autoscale quraraq, məsələn, CPU 70%-i keçdikdə yeni instans əlavə olunması qaydasını təyin edin. Bu, yük artanda sorğuların bir neçə instans arasında bölünməsinə və hər birinin yükünün azalmasına imkan verər. Autoscale mümkün deyilsə (məsələn, plan Free/Shared olduğuna görə), manuel olaraq planı Scale Up edin – məsələn, S1-dən S2-yə keçid CPU və RAM-i artıracaq. Unutmayın ki, Scale Up (yuxarı ölçüləndirmə) planın resurslarını artırır, Scale Out isə instans sayını. Hər ikisi performansı yaxşılaşdıra bilər. Microsoft-un tövsiyəsinə görə, əgər tətbiqin həqiqi ehtiyacı daha güclü VM-lərdirsə, planı daha yüksək tiera keçirmək lazımdır, yox əgər problem sadəcə müvəqqəti yük artışıdırsa, autoscale ilə instans sayı artırılmalıdır.
- Always On aktivləşdirilməsi: “Soyuq start” problemindən qaçmaq üçün App Service konfiqurasiyasında Always On funksiyasını açın. Bu, tətbiqin heç vaxt yuxuya getməməsini təmin edir, beləliklə uzun fasilədən sonra ilk sorğular artıq serverin oyanmasını gözləməyəcək. Microsoft tövsiyə edir ki, Basic və yuxarı planlarda Always On aktiv olsun, xüsusən də fon prosesləri və ya sürətli cavab verməli olan tətbiqlər üçün. Always On aktiv olduqda belə, deploy sonrası ilk yüklənmədə hələ bir qədər gecikmə ola bilər, amma tətbiq sonradan sürekli işlək qalır. Əgər tətbiq Azure Functions üzərində Consumption plandadırsa, onu Premium Plan-a keçirmək soyuq startı əhəmiyyətli dərəcədə azaldır.
- Asılılıqların optimallaşdırılması: Application Insights analizinə əsasən, konkret hansı asılı xidmətin performansı tıxadığı məlumdursa, o nöqtədə optimallaşdırma aparın. Məsələn:
- Verilənlər bazası: Yavaş SQL sorğuları üçün indekslər yaradın, sorğu planlarını optimallaşdırın. Azure SQL Database-də Query Performance Insight və Query Store kimi alətlərdən yararlanıb ən çox vaxt alan sorğuları təyin edin. Eyni zamanda, DB resurslarının (DTU və ya vCore, I/O) kifayət olub-olmadığını yoxlayın – bəzən database servisini daha güclü tier-ə keçirmək lazım olur ki, boğulma olmasın. Yadda saxlayın, bir sorğu uzun çəkirsə, App Service onu gözləyəcək; bu müddəti azaltmaq tətbiqin ümumi cavab müddətini azaldacaq.
- Xarici HTTP API-lər: Əgər tətbiq üçüncü tərəf API-lərə və ya mikroservislərə müraciət edir və onlar ləng cavab verirsə, cavab gəlməsini gözləyən çoxlu tələblər yığılaraq thread-ləri tutub saxlayır. Bu halı yaxşılaşdırmaq üçün həmin çağırışları paralelləşdirmək (əgər mümkünə), yaxud keşləmə tətbiq etmək olar ki, eyni məlumat üçün hər dəfə uzaq servisi çağırmayasınız. Həmçinin, App Service-dən çıxan HTTP çağırışlarına timeout təyin etmək lazımdır (sonsuz gözləməsin). Məsələn, HTTPClient istifadə edirsinizsə, onun timeout-u konfiqurasiya edilməlidir. Əgər mümkünüdürsə, xarici servislərin öz təyinatlarını yoxlayın – bəzən lənglik onların tərəfdəki problemə görə olur, onu aradan qaldırmaq lazım gəlir.
- Caching və Queue-lardan istifadə: Tətbiq eyni verilənləri tez-tez eyni mənbədən alırsa, Azure Cache for Redis kimi bir keşi araya qoyub təkrarlanan sorğuları sürətləndirmək olar. Eləcə də, istifadəçilərdən gələn bəzi ağır tələbləri birbaşa cavablandırmaq əvəzinə Queue arxitekturası ilə arxa planda emal edib nəticəni sonradan təqdim etmək performans problemini istifadəçi təcrübəsindən izolyasiya edə bilər.
- Kod optimallaşdırmaları: Profiler və logların işarə etdiyi kod yerlərini təkmilləşdirin. Məsələn, tədricən yaddaş artımına səbəb olan obyektləri düzgün dispose edin, lazımsız uzun dövrlərdən (loop) çəkinin, async/await istifadəsini optimallaşdırın. Nəticəsiz gözləmələr varsa (məsələn, bir HTTP çağırışı cavab vermədən əvvəl digərini gözləyir), mümkün olduqca onları parallel icraya alın. Application Insights Profiler-in göstərdiyi kimi, paralel icra oluna biləcək ardıcıl kodu paralel işlətmək performansı artıracaq. Kodda lock istifadəsinə xüsusi diqqət yetirin – geniş scope-lu kilidlər çox sorğu gəldikdə tıxanma yarada bilər.
- App Service konfiqurasiya və miqrasiya: Bəzi hallarda, performans problemi App Service planının tipindən qaynaqlanır. Məsələn, çox sayda kiçik fayl əməliyyatları aparan tətbiqlər üçün Windows-dansa Linux App Service daha performatlı ola bilər (çünki Linux konteyner kimi işləyir). Və ya App Service-in 32-bit modunda işləməsi yaddaş məhdudiyyətinə səbəb olub (İstifadə edilən plan və OS növünə baxın – Linux App Service-lər default 64-bitdir). Bu kimi parametrləri də gözdən keçirin. Həmçinin, çox kritik tətbiqlər üçün App Service Environment (ASE) variantı mövcuddur – izolə olunmuş mühitdə daha stabil performans verə bilər.
Yuxarıdakı addımlar nəticəsində, Application Insights-da orta cavab müddətlərini və asılılıq çağırışlarının müddətini yenidən təhlil edin. Gözlənilən odur ki, optimallaşdırmalardan sonra həm server tərəfindən işləmə vaxtı, həm də istifadəçilərin hiss etdiyi gecikmə azalsın. Always On aktiv edilibsə, soyuq startdan yaranan boşluq aradan qalxacaq və hər zaman sürətli cavab təmin olunacaq. Ölçüləndirmə tədbirləri nəticəsində isə istər CPU/RAM metri, istərsə də Request Queue Length stabilləşəcək (məsələn, queue length yenə 0 olacaq, CPU ortalama daha aşağı yüzdədə qalacaq). Nəhayət, istifadəçi təcrübəsi tərəfdən səhifələrin əvvəlkindən xeyli tez yükləndiyini və timeout hallarının yoxa çıxdığını müşahidə etməlisiniz.