Ons het gewerk in 'n gebruiker aanvaarding toets (UAT) omgewing wat, in vergelyking tot die ontwikkeling, is dood stadig.
Dit is 'n ingewikkelde omgewing met behulp van FBA, SQL 2008, SSRS en uitgebreide web programme oor die internet toeganklik met https, so dit is moeilik om die probleem op te spoor.
Vir 'n vorige kliënt, ons gebruik FBA met 'n LDAP rol verskaffer (en lidmaatskap verskaffer). One of my colleagues, baie meer slim as wat ek, determined that the "out of the box" LDAP rol verskaffer, wanneer dit gebruik word in daardie omgewing, wasn’t scaling well. To solve this problem for that client, he implemented a nice caching scheme in a custom role provider.
Hierdie situasie was soortgelyk, so we looked into replicating that solution to the today’s client. As I was debugging that, Ek het opgemerk dat hierdie boodskap gereeld sal binnekort in die stelsel log (van Event Viewer):
A worker process with process id of ‘XXX’ serving application pool ‘Home – 80’ has requested a recycle because it reached its virtual memory limit.
Ek het dit beteken dat die jeug swembad dusver was herwinning, veels te dikwels en dit sou verduidelik 'n prestasie probleem.
I looked at the app pool’s properties and its "Recycling" page showed that the property "Maximum virtual memory (in megagrepe)" had been set to true and had been set to 5000. That seems like enough, but I decided to unset the value and that had an immediate positive effect. No more app pool recycling. No more mysterious slow-downs and pauses.
I don’t really understand the underlying "stuff" wat gaan daar aan, maar dit is duidelik 'n soort van oorsaak / gevolg ding gebeur en vir nou, die UAT omgewing bruikbaar.
</einde>
Phil Wicklund