Am o aplicație web ASP.NET (.NET Framework 4.7.2.) implementată în AWS/ECS și am observat că Application_Start rula nu o dată, nu de două ori, ci de trei ori! Poate alții se confruntă cu această problemă.
Am rezolvat 1 din cele 2 reporniri suplimentare. Primul se întâmplă deoarece punctul de intrare docker al Microsoft ServiceMonitor's primul curs de acțiune este să opriți serviciul w3svc, să modificați applicationHost.config (prin appcmd.exe) pentru a injecta variabile de mediu la nivel de docker (cele furnizate prin directivele ENV în fișierul docker sau prin parametrii liniei de comandă rulați docker) în secțiunea variabilă de mediu a lui DefaultAppPool și apoi repornește serviciul.
De obicei, aceasta nu ar fi o problemă, dar dacă aplicațiile dvs. sunt setate să pornească automat cu preloadEnabled=true, atunci ceea ce se întâmplă este că serviciul pornește o dată, automat, cu containerul, numai pentru ca ServiceMonitor să vină și să-l oprească, modificați setările și reporniți-l din nou. Deci, rularea inițială inițială de sistem este condamnată și nu ar trebui să aibă loc în primul rând. Nu are toate variabilele de mediu așteptate și rulează într-adevăr doar pentru că aplicația este setată să pornească automat. Am rezolvat asta setând modul de pornire w3svc la „Manual”. Acest lucru împiedică rularea inițială condamnată a Application_Start, astfel încât, cel puțin într-un container docker local, obținem doar o singură pornire a aplicației, inițiată după ce ServiceMonitor a aplicat setările corecte.
Lucrurile stau puțin diferit în ECS. În plus față de rularea suplimentară de pornire declanșată de ServiceeMonitor, obținem și o altă (a treia) rulare declanșată de alte setări care sunt aplicate în timpul execuției, probabil de mediul ECS. Întrebarea mea principală este, știe cineva care ar putea fi aceste modificări ale setărilor instigate de ECS? ECS aplică variabile de mediu cumva sau face alte modificări la IIS în mod implicit? Acesta este ceva care se întâmplă numai în ECS și care nu are loc atunci când aceeași imagine docker este rulată local pe desktopul docker.
Oricare ar fi aceste modificări ale setărilor, ele sunt deosebit de perturbatoare, deoarece nu declanșează reciclarea normală a proceselor suprapuse care declanșează un proces nou, separat, care este încălzit înainte de a-l înlocui pe cel vechi. Aceste modificări ale setărilor declanșează tipul de reciclare în proces pe care l-ați obține dacă ați modifica un fișier web.config, de exemplu. Cred că aceasta înlocuiește AppDomain în procesul care rulează deja. Acest lucru este rău pentru noi, deoarece rulăm biblioteci de urmărire de nivel scăzut SignalFx care se conectează la CLR și provoacă o încălcare a partajării care blochează un proces atunci când noul AppDomain încearcă să încarce ansamblurile neutre de domeniu cu permisiuni diferite. Toate aceste cicluri suplimentare de pornire a aplicațiilor nu numai că provoacă încărcare suplimentară asupra sistemului, deoarece face triplu din toate (inclusiv hidratarea cache-ului din bazele de date, configurarea abonamentelor la subiecte Azure etc.), dar impun și solicitări suplimentare de memorie asupra sistemului, care poate duce la excepții OutOfMemory, în special în docker, unde containerele au o limită de memorie.
