Load already rendered bundle

[IT Man]

Hello,

I'm using Squishit in MVC project with 2 different layouts, like this:

     @Html.Raw(Bundle.Css()

                .Add("/Content/Styles/Shared/all.css")

                .Add("/Content/Styles/Site/screen.css")

                .Add("/Content/Styles/Site/javascript.css")

                .Add("/Content/Styles/Site/pre-beta.css")

                .Add("/Scripts/tiny_mce/style.css")

                .Add("/Content/Plugins/Jquery.UI/theme.css")

                .Add("/Content/Plugins/Fancybox/jquery.fancybox-1.3.4.css")

                .Add("/Content/Plugins/Social-media-tabs/dcsmt.css")

                .Add("/Content/Plugins/Jquery.PeelBack/jquery.peelback.css")

                .Add("/Content/Styles/Shared/xtech-extension.icon-fonts.css")

                .Add("/Content/Styles/Shared/xtech-extension.loginbox.css")                

                //.ForceRelease()

                .WithMinifier<SquishIt.Framework.Minifiers.CSS.YuiCompressor>()

                .Render("/Content/service_combined_#.css"))

Till now application startup was taking about 2-3 mins.

Recently new layout have been added and startup takes about 15 mins when compression for added layout is enabled.

In this case i would like to prepare compressed files outside production enviroment, and just place them in the right place.

So here's my question: how to tell squishit not to render new file each time aplication is started? 

Instead i would like SquishIt to load a file that is already there.

PK

[IT Man]

Hello, i have previewed source code, and there seems to be strange behavior for Squishit that pull down performace:

1. I start the web application.

2. Squishit Cache is empty (right?)

3. Application gets immediately hit with multpile requests.

4. Each request calls .Render method.

5. I can see any lock for multiple parallel file processing - so i assume that each request runs separate compression procedure.

6. That seems to hit performance badly.

Am i missing something?

[Alex Ullrich]

You are kind of right, at least in low trust scenarios.  CriticalRenderingSection is used in an attempt to mitigate that problem, but it only works in full trust in .net 4 and forward (which is all we support now).  https://github.com/jetheredge/SquishIt/blob/master/SquishIt.Framework/Utilities/CriticalRenderingSection.cs

Typically the way I get around this is to have code that defines and renders all bundles somewhere in the OWIN startup process, then for most runtime scenarios renders them from the cache.  As long as you have a stable platform this limits rendering to the first request, which you can often initiate before a server is in the wild in web farm scenarios. 

What is your environment like that startup is taking 15 minutes (or even 2-3?).  That seems very high for a .net application, almost seems to suggest excessively slow I/O or low memory.  Are you sure it is SquishIt taking that time?  How big is your combined CSS file?  

You could certainly put your combined files on a CDN and plug in a no-op renderer to achieve what you are after but at that point I think you are kind of fighting with SquishIt, which makes some concessions that hurt runtime performance pursuit of a smoother development and deployment workflow.  There is other tooling that can do what you are after more easily I think.  Newer versions of visual studio have gulp/grunt support, and I have always liked Bundler (which ironically SquishIt used to be called, before Justin changed it to a different name than the ruby library).  You may want to look into those options https://github.com/ServiceStack/Bundler

I would really like to know more about your setup and why startup is so slow.  It might highlight a problem that I have not noticed.

[IT Man]

Thanks for your answer!

Well...

Issue seems to be solved at the moment. I have been using version 0.8.2.0 which seems to not have improvements you've mentioned.

Upgrading was first thing for me to do, but i haven't noticed that nu-get didn't swap references properly. When i have fixed that, startup time dropped to 30s in production enviroment.

I can provide provide you enviroment configuration if you like, but don't now if it still makes sense now?

When it comes to conclusions:

Current version 0.9.9 works fine for me. If i could propose some improvement's i would like to see rendering procedure as "background process" initialized with first request but not pending this request. Till rendering finishing squishit could serve not compressed css and js files (like in debug mode). Once render finishes (cache gets filled) any other request would receive compressed version (production). That would compromise immediate application availability to users and need for script compression.