hi all,

I'm currently doing a stress-test on dotnetnuke (4.5.3- running on windows 2003/SQl Server 2005)  to see its scalability when run in a web farm. For our test environment, we have a cisco CSM Load Balancer doing round robin to 2 web/app servers. When I run any sort of concurrent users (as low as 20), I am getting error 500s which state "The process cannot access the file '\\xxx\appshare\ExecutivePortal\DotNetNuke_2\website\Portals\_default\Cache\UG9ydGFsMg==.resources' because it is being used by another process.". I looked up this directory, and how it is used by the DNN caching mechanism, and I don't understand why there would be contention on this file. Whenever we shut one of the web servers off (and hence don't have competing worker processes going after each of these files), we get no errors, even if we put hundreds of virtual users on the server. 

We have set the webfarm attribute in the web.config to true, followed the directions for the recommended configuration in the webfarm doc by Dan Carron, and have the following settings for DNN (although we have tried various permutations with no luck).

 

Page State Persistence: Select the mode to use to persist a page's state. This can either be a hidden field on the Page (Default) or in Memory (Cache).	Page Memory
Module Caching Method: Memory caching provides the most flexibility and is the highest performance method however it also consumes the most system resources. Disk caching is the least expensive on resources but does not offer any flexibility.	Memory Disk
Performance Setting: Select how to optimize performance.	Clear Cache
Authenticated Cacheability: Sets the Cache-Control HTTP header value for authenticated users.
Compression Setting: Select the type of Http Compression to use.
Use Whitespace Filter:

The other error we get on these files is "Access to the path '\\xxx\appshare\ExecutivePortal\DotNetNuke_2\website\Portals\_default\Cache\UG9ydGFsMg==.resources' is denied." This is baffling as well since the app-pool we are using (we did define our own), the IIS virtual directory mapped to the share, and all relevent file structures are set to allow full access to the user we are running as.

Any help with this would be most appreciated, as we've spent quite alot of time trying to resolve it.

thanks,

Phil

 

 

Thanks John, but I guess I'm confused how DNN says it can handle a web farm environment but based on what you say and what we have experienced, it really can't by default. I'm going to try changing the caching provider to broadcast/polling since the doc said you could do that in a central file system setup even though it wasn't the recommended provider. We will also look into hacking the file based caching provider if needed. If anyone else has already modified the file-based caching provider to accomodate this, I'd love to know what is needed.

We were using the FileBasedCachingProvider and suffered from the same issue you described above. Our environment is under an extremely high load and the error was happening constantly and filling up the logs. We switched to BroadcastPollingProvider and have had no issues with that error anymore. My only gripe about it is that if you add a page, module to a page, or change any content/permissions that are cache based, your change will only be reflected after the polling provider scheduler interval is reached (30 seconds by default). This really confused our content administrators because they would create a page and then another server in the farm would handle the subsequent request and not no about the page until the broadcast scheduler would run. Anyways, it is better that than to suffer from errors. We are glad to hear that the FileBasedCachingProvider is being updated in the next release. Thank you team!