Ние сме работили в потребител приемане тестване (ДОСТАВКИ UAT) среда която, в сравнение с развитието, е мъртъв бавно.
Това е една сложна среда, използвайки FBA, SQL 2008, СРИС и разширен уеб приложения достъпни през интернет с помощта на https, така че е трудно да се открие проблема.
За предишния клиент, Ние използвахме FBA с доставчик за ролята на LDAP (и доставчик на членство). Един от моите колеги, далеч по-умен от мен, установили, че "извън кутията" LDAP роля доставчик, Когато се използва в тази среда, не мащабиране добре. За да реши този проблем за този клиент, Той изпълнява хубава схема за кеширане в доставчик на потребителска роля.
Това положение изглеждаше подобни, така че ние погледнахме в реплициращата това решение на днешния клиент. Както е грешки,, Аз забелязах, че това съобщение ще се появяват често в дневника на системата (от събитията):
Работен процес с ИД на процес на "XXX’ обслужващи набора "Начало – 80’ е поискал кошчето, защото той достигнал лимита за виртуална памет.
Взех това да означава, че ап басейна е рециклиране далеч, твърде често и това обяснява проблема изпълнение.
Погледнах в ап басейн свойства и неговите "рециклиране" страница показа, че свойството "максимална виртуална памет (в мегабайти)" са били определени true и са били определени 5000. Това изглежда достатъчно, но реших да унищожава стойността и че имал непосредствен положителен ефект. Няма повече ап басейн рециклиране. Няма по-загадъчна забавяне спадове и паузите.
Аз наистина не разбирам основните "неща" Това се случва там, но ясно някаква причина/ефект нещо се случва и за сега, доставки UAT среда е използваем.
</край>
Phil Wicklund