Archive
Monthly
Go
|
|
DNN Blog
Mar
22
Posted by:
Alec Whittington
3/22/2007
Today we are going to look at improvements to the Compression Module for DotNetNuke 4.5. These were confirmed using DNN 4.5 RC2.
Let's start with a little history. Early versions of DotNetNuke had no provisions for page compression. There were options, such as the Blowery HttpCompressionModule, but they generally required the user to modify the default installation of DNN. In addition to modifying the application, you also had to manually exclude paths and mime types. If you wanted to upgrade your site, you had to modify the web.config to remove the compression. If you did not, hold on it is gonna be a long night.
Starting with version 4.4 of DotNetNuke, compression was implemented in the core. This was a nice feature for many people, but for just as many it was a source of problems. Most problems were found to revolve around the fact that the user had to exclude mime types and paths via the compression.config. This could often lead to a trial and error process that would quickly sour the user experience as well as increase the number of problems an implementor had to deal with. After a thorough review of the problem, it was decided that Default.aspx was the only page that needed to be compressed. Enter DNN 4.5.
Starting in version 4.5, the compression module will only compress the default.aspx page. The end user will no longer have to set-up excluded paths or mime types. You can still exclude paths via the Host Settings -> Compression Settings -> Excluded Paths field. The proper format for this would be TabId=xx, where xx equals the actual number of the TabId. This feature is there in case there is a page (tab) that is giving you problems do to compression. So if I create a page named AlecTest, TabId 357, that has a module on it that is giving me trouble do to the compression, I can then exclude it by adding tabid=357 to the Exclude Paths field.
Overall, I think the improvements are going to eliminate a large number of problems that users were seeing with HTTP compression in DotNetNuke. Under a default installation, the default home page was returning 44k in text. After turning on compression, that shrunk down to 17k. This is a significant savings of bandwidth over many requests.
11 comment(s) so far...
Re: Improvements to Compression Module
"hold on it is gonna be a long night". That made me laugh out loud. Great post.
By AdefWebserver on
3/22/2007
|
Re: Improvements to Compression Module
Curious, how does this relate to IIS compression? That is, if you have the option of using IIS compression, would you use it or the new compression built into 4.5?
By RockyMoore on
3/22/2007
|
Re: Improvements to Compression Module
This is more for user who do not have access to there IIS server (hosting environment), or corporate policy that IIS compression is not allowed to be enabled. If you have full access to the IIS server then it is up to you whether you want to use IIS built-in compression or DNN built-in compression.
By smehaffie on
3/22/2007
|
Re: Improvements to Compression Module
"If you have full access to the IIS server then it is up to you whether you want to use IIS built-in compression or DNN built-in compression." - Now that's interesting... I wonder if ASP.NET can detect if IIS compression is switched on? If so, DNN should really detect this, and if IIS compression is enabled it shouldn;t really offer the facility (and inform the host that IIS compression is enalbed).... feasible?
By NukeAlexS on
3/22/2007
|
Re: Improvements to Compression Module
I wish I could edit my typos here :)
By NukeAlexS on
3/22/2007
|
Re: Improvements to Compression Module
It is a setting that is in the IIS Metabase. It could most likely be detected via WMI, but then that would require elevated permissions as well.
By ncgoose on
3/22/2007
|
Re: Improvements to Compression Module
Well, lets not forget that the IIS compression is going to require you to do all the configuration settings and exclusions that we just spent 4.5 removing from DNN. IIS compression is likely to provide more power, but that comes at a price.
By jbrinkman on
3/22/2007
|
Re: Improvements to Compression Module
in the past i had tons of problems with compression, i hope in the next version we will have stabilization release.
Turkish translation of article: http://www.mikroproje.com/tabid/144/articleType/ArticleView/articleId/47/Compression-Modlnde-Yaplacak-Deiiklikler.aspx
Regards
By greenflash on
3/23/2007
|
Re: Improvements to Compression Module
Just to add to Joe's comment. IIS has NO UI for managing its compression (its just ON or OFF) - and having attempted to do it while at MS working in the Patterns and Practices lab, it is not a trivial process - it is even more arcane than the config file we used.
By cnurse on
3/23/2007
|
Re: Improvements to Compression Module
I use Port80 for configuring IIS native compression. Works very well for me.
By mariette on
3/24/2007
|
Re: Improvements to Compression Module
Did the compression of text files such as javascript or css (especially the solpartmenu) cause any problems? Even though they only download the once, its that 'first impression' delay that causes a perception that performance aint so great...
Great to hear that at least most of the problems with the compression have been clobbered though!
By bramborak on
3/26/2007
|
|