Hey everyone,

I went from 4.6 today to 4.8.  I run some fairly large DNN portals of the same directory, but different IIS configs. They all use the same application pool specifically for DNN.  Anyhow, after the upgrade, I found myself wondering what the heck was going on. It was taking FOREVER to load up.   I took at look and SQL server was running at nearly 100%.  SQL (2005 standard) only serves out one DNN database. I waited like 20 minutes for the 6 different IIS instances to load, but it still didn’t. I tried restarting IIS, Restarting SQL, and then even restarted the whole server. As soon as the application space goes to load, SQL just starts going crazy.

So, I opened up the profiler, and watch.. there were hundreds of thousands of queries happening.. all for DNN. I looked at many of them, and it almost appeared that it was querying each and every page, pulling everything from each module down to their security levels.   I was seriously stunned that it was not going to pull it on demand.. it was pulling everything on application start.

So, I moved my database to another server in my production line.. Core 2 2.66 with 4GB ram.  It hosts hundreds of websites, and it hardly even sees 2 or 3 percent CPU.  As soon as I started my applications, even that server topped out SQL server.   So, I started each IIS instance one at a time, and watch.. even the network traffic had huge spikes.

So, my question is.  What has changed from 4.6 to 4.8 that would just pound the crap out of SQL server?  Am I the only one seeing this problem?  Any previous version never saw this issue.  This its new for either 4.7 or 4.8.   My other server, which hosts just one instance of DNN and the database runs great with 4.8, but we have 30+ portals on this one instance, and 7 different IIS webs pointing to the same directory on the server.

Thanks. Any response would be greatly appreciated. 

I have a lot of modules installed.   I will ctrl-v them right now ;) - I hope this works.. its all HTML, and I dont know if you permit that in your DNN posts.

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: Select this to remove excess white space from the response sent to the client - this will result in a smaller download (10-15%) but it will make the html less readable.

Even on a fresh reboot of the server, and DNN + SQL are the only things running... the resources are free.  It has 2.5 GB of memory, on a 2.4 Dell Server.    Even when Moved my database over to the other server, it was still hammering the hell out of it, harder then any other version we have had or used.  The modules had not changed, just after the upgrade, DNN took a seriously long time to execute.  Once I was able to get one of the modules to load, I turned of all the schuduling as that may be what was causing it.  putting the database on a different server has seriously helped the performance of the system, but I just dont know why it needed that just so it would start to work. 

Was their any changes wher the system would preload every page in the system?  We have over 1100 tab ids between all of our portals.  I even attempted to use ngen to help the loading process, but I didnt see an improvement.