Imxejna ilhom jaħdmu fil-ittestjar ta 'aċċettazzjoni utent (UAT) ambjent li, meta mqabbla ma 'l-iżvilupp, hija mejta bil-mod.
Huwa ambjent kkumplikata tuża FBA, SQL 2008, SSRS u l-applikazzjonijiet estiżi web aċċessibbli fuq l-internet li jużaw https, hekk huwa kien diffiċli li jillokalizzaw l-kwistjoni.
Għal klijent preċedenti, aħna użati FBA ma 'fornitur rwol LDAP (u l-fornitur sħubija). One of my colleagues, ferm aktar għaqlija minn I, determined that the "out of the box" Fornitur rwol LDAP, meta jintuża f'dak l-ambjent, wasn’t scaling well. To solve this problem for that client, he implemented a nice caching scheme in a custom role provider.
Din is-sitwazzjoni dehret simili, so we looked into replicating that solution to the today’s client. As I was debugging that, I ndunat li dan il-messaġġ se spiss jidhru fil-log Sistema (minn Viewer Avveniment):
A worker process with process id of ‘XXX’ serving application pool ‘Home – 80’ has requested a recycle because it reached its virtual memory limit.
I ħa dan ifisser li l-pool app ġie riċiklaġġ ferm, wisq spiss u li jispjega l-problema prestazzjoni.
I looked at the app pool’s properties and its "Recycling" page showed that the property "Maximum virtual memory (fil megabytes)" 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" li għaddej hemmhekk, iżda b'mod ċar xi tip ta 'kawża / effett ħaġa jiġri u għal issa, l-ambjent UAT tkun tista 'tintuża.
</aħħar>
Phil Wicklund