Performance tuning for ASP.net based sites including DNN

Posted on by

The following are possible causes for the  slow performance of ASP.net sites (including DNN sites):

  1. Slow initial page load (applies to any ASP.net based site, including DNN)
    • JIT Compilation delays: Each site site is configured with it’s own application pool, which spins off a worker process, the host process for your site’s code (whether ASP, ASP.net, PHP, etc).  This is the process isolation model for IIS, your code executes in your own application pool, the next customer’s in his own application pool.  Our default idle timeout on the application pool is 5 minutes.  That means if you have no activity on your site, the application pool spins down the worker process for your site… after all, no need to consume the memory used by that process, if no one is actively on the site.  This is one of the foundations of SHARED HOSTING on IIS… if a site has no activity, the memory usage of that site is minimal or none.  It’s a bit like phone line consolidation… if you’re in an office building, not everyone can pick up the phone and make a call simultaneously, as there generally aren’t enough lines for that many concurrent calls.  Instead, there’s an assumption that only X phone calls will ever be made concurrently.  The usage model for hosting makes the same assumptions of limited concurrency.  And this works fine for ASP and PHP sites, where spinning up the worker process for the next site visitor, and loading the ASP or PHP runtime engines into that application pool’s worker process takes a split second, having minimal impact on site load time.  But with ASP.net a different model was introduced.  With ASP.net sites, your code is actually compiled at run time, JIT or just-in-time compilation.  .Net assemblies are created from that compilation activity, and then cached.   So that first hit of the site causes a delay, while waiting for the JIT compilation.  The next hit, is very fast.  And the following hits are also fast… up until you have a period of idle (no hits) longer than the application pool idle timeout… which then shuts down the worker process.  On the next hit, the JIT compilation happens again… so again you experience the delay.  The symptoms most would describe with this are “the first time I hit my site it’s VERY slow to load, subsequent hits immediately after that are quick.  however if I wait 15, 20, or 60 minutes, and hit the site, that first page load is slow again.  and again, subsequent hits are fast”.
    • To address this, 3Essentials will gladly disable the Application Pool Idle Timeout value on your Application Pool(s) at no additional charge for any customers whose plans include ASP.net for their domains that are actively using ASP.net.  When you request this, we’ll also disable the default “daily recycle” of the worker process (unless you specify otherwise).  This is a regular recycling of the application pool designed to recycle the application pool once every 27 hours to help keep the process healthy (mostly intended to clear memory usage by the process in event your code or a module within your code has a memory leak).  You can request we do not disable this, or that we set it to a different schedule – just specify your requirements in your support request.
    • This stopping of condition can also cause the “Validation of viewstate MAC failed” as discussed in http://knowledge.3essentials.com/web-hosting/article/504/ERROR-Validation-of-viewstate-MAC-failed.html
  2. Debugging enabled in web.config file (applies to any ASP.net based site, including DNN)
    •  If you have the following parameter in your web.config file, you are causing a dramatic performance impact to your ASP.Net based site:
      • <compilation debug=”True”>
    • In item one above, the JIT compilation of ASP.net was explained… this compilation process is modified when debugging is turned on.  Instead of batch compiling all of your ASP.Net files into a single assembly into the ASP.net compilation cache, ASP.Net will compile each file individually, and create a unique assembly in the compilation cache.  This dramatically slows the process, and significantly increases CPU and disk I/O associated with this process.  Microsoft strongly recommends that you NEVER enable debugging in a production environment.  Please remember, our shared hosting servers ARE a production/live environment.  You should do your testing and debugging on your own test/development environment first, and only deply your production ready code to our environment.
    • You should check to see if you this debug parameter enabled in your web.config file, if you do, disable it by changing the value to False.
  3. DNN – Excessive log Files
  4. DNN – scheduler
    • There could be various schedulers that might be used with DNN. An example would be using a scheduler to send the newsletter. This tries to send email with senders email. But if it’s a non authenticated user, like it’s non email user of the domain you won’t able to send the mail. To check this,you could schedule the scheduler to send two  mails in  a minute to know what went wrong, This is fine but if the mail is not send , these data is captured as logs and and will be running always till you stop it.  So running of  schedules causes slowing down the site.  One thing to note is there are certain schedulers which are to purge certain data after use and this should be deleted from the DNN. For more details on these you can always check out the details at  www.dotnetnuke.com
    • Large sites need to modify the frequency of the “Search Indexer” task as it can eat up resources if left at it’s default value.
    • Also in general tasks should only run as frequently as possible AND the scheduler mode should be set to Timer and not the default of Request.
  5. DNN – Upgrade (known issue with DNN 4.6.0, may apply to other versions)
    • When upgrading a DNN installation, your caching settings may get altered automatically. It is recommended to set its value to HeavyCaching to improve perfomance
    • Also the site log settings may be TURNED ON automatically during an upgrade. A large number of entries in the sitelog can degrade performance. By disabling the sitelog; DNN performance can be improved to a great extent.
  6. DNN – Apply Mitchel Sellers’s recommendations for How I Get My DotNetNuke Sites To Run So Fast
  7. ​DNN – We also recommend anyone concerned with performance of their DNN site also review the following articles:
Posted in ASP.NET Hosting, DotNetNuke, Windows Web Hosting.

Leave a Reply