Am fost de lucru într-un testele de acceptare utilizator (UAT) mediul care, în comparaţie cu dezvoltarea, este mort lente.

Este un mediu complicat, folosind FBA, SQL 2008, SSRS şi aplicaţii extinse web accesibile pe internet, folosind https, Deci, a fost greu pentru a urmări în jos problema.

Pentru un client anterioare, am folosit FBA cu un furnizor de rolul LDAP (şi calitatea de membru furnizor). Unul dintre colegii mei, mult mai inteligent decât mine, stabilit că out"din caseta" Furnizor de rolul LDAP, atunci când este utilizat în acest mediu, nu a fost scalarea bine. Pentru a rezolva această problemă pentru acel client, El a implementat un sistem de cache-ul frumos într-un furnizor de particularizată.

Această situaţie părea similare, aşa că am căutat în replicarea că soluţia pentru client de azi. Aşa cum am fost depanare care, Am observat că acest mesaj ar apărea frecvent în Jurnalul de sistem (din vizualizatorul de evenimente):

Un proces de lucrător cu ID-ul procesului de ' XXX’ care deservesc aplicații ' Home – 80’ a solicitat o reciclare pentru că a atins limita de memorie virtuală.

Am luat acest lucru să însemne că piscina app a fost reciclarea departe, departe de prea multe ori şi care ar explica o problemă de performanţă.

M-am uitat la piscină app proprietati si sa "reciclare" filme a arătat că proprietatea "memorie virtuală maxim (în megaocteţi)" a fost setat la adevărat şi au fost stabilite 5000. Asta pare destul de genul, dar m-am decis pentru a demarca valoarea şi că a avut un efect pozitiv imediat. Nu mai multe app piscina reciclare. Nu mai misterios încet-coborâşuri şi pauze.

Eu nu prea inteleg care stau la baza "chestii" ce se întâmplă acolo, dar în mod clar un fel de cauza/efect de lucru se întâmplă şi acum, mediul de UAT este utilizabil.

</scop>

Aboneaza-te la blog-ul meu.