I blogged about it a while ago: http://www.dnnsoftware.com/community-...
I was able to tame SQL resource utilization by improving DNN SQL procedures, views and indexes - check out my Turbo Scripts, but please start with a database backup. It will also not affect performance of 3rd party extensions.
Please be aware that File Compression, CDN etc. does not affect SQL Server resource utilization.

---

Cheers from Germany,
Sebastian Leupold

   

Speed up your DNN Websites with TurboDNN

Sebastian, So I had a thought about what could be causing both the high SQL CPU and timeout.  How many data throughput/transaction units (DTUs) in Azure SQL do you think the user account authorization would take?  Is it possible I am hitting my current limit of 5 DTUs with just that one action?  If so then that could explain the timeouts.  It might also explain why I cannot replicate the issue in my lab, since there I do not have a throttle imposed.  It might also be why I did not experience this even using a shared hosting SQL, because although I might have been competing with other websites hitting the shared SQL there was not a throttle put on my website accessing the SQL Server.

 

According to the documentation, a DTU is equal to one transaction per second. So 5 DTUs would be a limit of 5 data transactions per second. Once that cap is hit as I understand, other connections are rejected.

I still have my 5.6.8 running at my old shared hosting provider with a separate url.  During the migration to Azure, several users had registered. So I went to gather those emails, so I could let them know they needed to re-register.  I used the host account to do this just to see how long it would take. The user account screen for the first one came up within 2 to 3 seconds. The others pretty much about one to two seconds.  This 5.6.8 installation still has all of the deleted unauthorized users - none have been removed. No performance enhancements made to the site and yet it responds faster by 30 to 60 seconds faster when bringing up a user account to authorize it.  The only things I did with the new site with users was to remove the profiles from the indexer so they do not show up in search results and remove all of the deleted unauthorized users.  I checked folders in the new 7.4.2 and there are only about 10 to 20 folders there with files.  I recognize all of them as regular users, so no unauthorized users with physical folders in that portal. 

Something either I did during the migration, or with the various upgrades from 5.6.8 to 7.4.2 or something in 7.4.2, or with Azure has resulted in a 15 to 20 times slower access with editing a user account????