A guest post by Rick Barber – a senior technical lead over at managed Windows host OrcsWeb:
At OrcsWeb we recently came across an issue where a user was having performance issues with a bare-bones Orchard installation on a shared server. We tried to reproduce the issue and sure enough, any time the site was browsed to it took about 20 seconds to load.
Initial troubleshooting identified the cause for the 20 second load times: the application pool was constantly recycling because it was hitting the virtual memory limit. Great! Now we knew what was going on and could begin our quest to get to the root cause of the recycle.
The next obvious place to look was the memory settings on the application pool. Since this is a shared server there are memory limits in place. Orchard takes a large chunk of memory for the initial compile which was causing the application pool to hit the virtual memory limit. We increased the virtual memory limit to 2 GB and the application pool was still recycling, just not as often. We set the virtual memory limit to unlimited and the application stabilized and we continued to monitor it. Setting Virtual Memory Limit (KB) to 0 effectively allows it to use unlimited memory as shown above.
A short time later we noticed that the application was using over 5 GB of virtual memory. We tried some other memory settings but they all caused the application pool to recycle frequently.
After more investigation we noticed that the application pool was running in 64-bit mode. Since that setting allows more memory use for an application, we changed it to 32-bit mode. Setting ‘Enable 32-Bit Applications’ to True sets the application pool to 32-bit. Almost immediately the application started running properly.
We were then able to go back and set a reasonable amount of virtual memory to the application pool. The Orchard site continues to run properly utilizing less than 800 MB of virtual memory.