Hosting environment can certainly affect performance and stability, however DNN itself can introduce a lot of variables especially when third party modules are introduced in to the mix. People often confuse DNN with a typical html webpage, which is a wrong assumption although on the surface it may appear as such. DNN is a complex dynamic data driven application that is executed on the server, it needs to be maintained in order to perform well. Also, when you design your pages try to minimize the use of modules. Every little “do-hicky” you add to your pages adds the number of database queries per view, increases the cache memory requirement, bloats the HTML output size, and increases the browser render time. On top of it all, the database itself requires regular index rebuilds in order for SQL database queries to execute within reasonable amount of time.
Some of the things like SQL database re-indexing and query plan optimization your hosting provider can do for you. For example we have an automated table re-indexing and query plan recalculation that occurs weekly on all customer databases, this is just a good housekeeping since it helps our database servers to chug along much better and helps our customers. Besides that, regular EventLog and SiteLog table truncation is a must, these tables tend to grow fast and fragment the database file groups.
Here is what you can do on your end if you are hosted in shared hosting environment:
Page state persistence: Page (this will help to reduce work process memory consumption)
Module caching method: Disk (Work process memory is a premium resource on the shared hosting servers)
Performance setting: Heavy caching (This will reduce database IO = better performance)
Compression setting: No compression (Although the idea behind the HTML output compression is good, in reality the CPU overhead makes it slower than raw output)
To truncate logs from your database use this TSQL script:
USE
YOUR_DB_NAME --Replace "YOUR_DB_NAME" with the name of your database
GO
TRUNCATE TABLE SiteLog
GO
TRUNCATE TABLE EventLog
GO
Perhaps the #1 complaint we get from our users is; “My site takes up to 10 seconds to load”. I don’t care how many CPUs your server has and even if your domain is the only one hosted on the server, ASP.NET application such as DNN will take anywhere between 4 to 15 seconds to load if the work process has been dormant. I’m not going to discuss .NET JIT and other techno topics that cause this, but the best analogy as to why this happens can be found on your own desktop. For example, when you open any application such Microsoft Outlook for the first time, the computer has to load data from the hard disk in to the memory, then CPU starts to execute the byte code and application becomes active. Same thing happens on the server when you access DNN or any other ASP.NET site for the first time. The IIS server creates a work process, loads .NET framework, then your application, after that the actual application has to connect to the database server and load the data in to cache, then render it as HTML output that is sent over the internet to your browser. As you can see, even when simplified there may steps that have to happen just right in order for your DNN installation to work. Add a bit of ambient load on the server , poorly optimized DNN installation and buggy 3rd party modules and you have a mess on your hands.