2.0 speed/performance concerns

Yeah, the process Idle Timeout is set to 20 minutes. Let me fix that, thanks.

theonlylawislove wrote:
Paul,
According to the following post it's improved in the latest version of Entity Framework - http://blogs.msdn.com/b/adonet/archive/2011/06/30/announcing-the-microsoft-entity-framework-june-2011-ctp.aspx. But... it's just a CTP version. So let's wait for RTW

There is always an easy fix when push comes to shove, you can always put up a spinning wheel when the user clicks on a link. It tells the user that the website is doing something.

By the way Andrei, great job!

With regards to the IIS Application Pool first compile/start up issue - the App Warm-Up IIS module from Microsoft may help: http://www.iis.net/download/applicationwarmup.

I hope this helps,

Chris

chris_rowtcliff wrote:

Nope, this isn't available anymore.

I've posted some performance notes here:

https://www.nopcommerce.com/boards/t/10741/nop-20-beta-performance-notes-some-results.aspx

In general 2.0 feels fast. One area that is still unacceptably slow (in real world) out of the box are Category Pages, especially if one increases the number of products shown on one screen (20+).

Filip

wow this thread could be copied from the Orchard Project a version or two back. Same really long load times after app pool shutdown, etc. The module architecture prevents precompilation of the project, so every time the app recycles, it seems to perform a full recompile on the first new request. It's still somewhat of a problem for them, I personally solved it by adding a remote ping service to hit my sites every 15 minutes or so.

boomhauer wrote:

Hmm well that makes sense, even though I don't experience the performance issue with the queries I am having a similar issue with when the site sits idle for a while. I was figuring it was the app pool settings.

But now that you mentioned it I do remember when I was testing orchard that it had a similar issue and sort of still does...and I was suspecting it to be having to do with how they do the plugin/modules.

I believe Nop took some of the same design from both orchard and Umbraco as I see references to both in the source...where they gave credit where credit was do.

I was actually surprised they just didn't utilize MEF to do the plugins... I've used it with MVC and it works great and fast too.

Just out of interest, does anyone have a list of what is being cached (or what should be being cached) on 2.0 and maybe from 1.9,

1) No Caching - ?
2) Per Request Caching - ?
3) Caching For All Requests - ?

We had a look at Nop.Web.Framework.DependencyRegistrar and saw all the IOC regsitration calls registering the singletons cached instances etc.

We also noticed that this really only seems to perform "Per Request Caching" for the majority of items.

With the exception of SettingService and LocalizationService which are using "nop_cache_static" - so this is cached across multiple calls.

Conclusion
Although some of the "service" classes use the CacheManager, this defaults to using the "nop_cache_per_request" caching.

So... I guess adding more caching as the majority of the content on any given page (such as home page) is being retrieved from the database and rerendered for every request (GET/POST).

From what I can tell, without any multiple call caching, this would explain the speed. You could confirm this by using SQL Profiler and taking a look at all the DB calls.

Thoughts anyone?

We are also taking a look at AutoMapper which seems to be a bit on the slow side.

Are there any plans to use multiple (alternative) "mapper" systems? Let me elaborate, we have the benefit of our systems running in full trust and would like to see if we can gain some performance by using "Emit Mapper" (Full trust) rather than "AutoMapper" (Medium trust).

http://emitmapper.codeplex.com/

From the very brief trawl on the net of speed comparisons between (comparison results found online),
1) Hand crafted "mapper"
2) Auto Mapper
3) Emit Mapper

Emit mapper came close with hand crafted and auto mapper would appear to be much slower by a substantial amount. The very quick test we wrote had us getting 50 records out of a local DB retrieve (10ms), AutoMapper (85ms) and about 20ms infrastrcuture calls which we didn't look into. We also tried a "hand crafted" mapper (0 ms) and also a EmitMapper version (0 ms).

And for those of you who don't know what I'm talking about, there is a conversion step going from "Model" to "View Model" when the controller "actions" run. The model needs to get copied into a very similar but different model (view model), this copy mechanism is done using a mixture of hand crafted and AutoMapper code. This post is indicating a slow down for automapper.

Hmmm... thoughts?