Substantial bottle neck in nopCommerce 3.0 catalog pages!

a.m. wrote:

Hi Andrei,

The changeset did fix the problem!
Please see these two snapshots for a comparison:

http://www.nop-templates.com/filtersSnapshot1.jpg

http://www.nop-templates.com/filtersSnapshot2.jpg

We are keeping two separate branches, one before the changeset and one with the changeset. The two snapshots are from these branches.

However this does not explain why the Category action does not have this problem although it calls PrepareProductOverviewModels with the same products. Also why specifically the GetCurrencyById? Really, really strange!

We will continue looking at this as we need to find out why this happens.

But to answer your question the changeset did fix the problem.

Many thanks for this!

significantly improved without the 7 Spikes Mega Menu enabled.

7 Spikes, will you be releasing an update or do we need to implement the changeset and recompile?

Todd

Something is still wrong:
My results with loading a category containing 70 products on one page:  (our live database was converted to version 3.0  all test were run on the same server. plain vanilla nopCommerce, no addons at all)
v.2.65                                 3.5 s
v.3.0 before the changeset:   21 s
v.3.0 after the changeset:     16 s      (somewhat improved, but still unacceptable)

What do you suggest ?  
I now try to add these 70 products only the empty/demo database and rerun the test.

thinton99 wrote:

We have already released a fixed Nop Mega Menu, including the changeset and an optimization fix of our own. We are continuing to look at the plugin and the performance as we believe there might be other bottlenecks.

Please download it from Nop-Templates.com and let us know how it goes.

You might want to write in our forum or directly to [email protected] in order to get a fast response!

7Spikes, I emailed support directly over 8 hours ago as you suggested, but got a quicker response here.  I downloaded the latest mega menu from my account, but still getting terrible performance so disabled the menu.  Do I need to implement the changeset?  What changes does your update implement?  Didn't seem to make any difference.

Please advise.  Thanks.

Todd

libor wrote:
Could you please share your 3.00 database backup so I can test it?

I've just added 100,000 test products (mapped to categories, manufacturers, tags, etc). And everything works just fine (<1 second) even with 70 products on one single category page. Proof - see this screenshot (http://img521.imageshack.us/img521/5137/300performance.png) with time required to load the page at the top left corner.

So please share your test database so I can test it.

Thank you Andrei for looking at my case.  I am just removing customer data and will send you the link within an hour (both to our test-site and also the database backup you can download) in PM.

libor wrote:
OK. So I've tested your database (locally) and found two bottle necks:

1. On your tax settings page you have "tax based on" set to "Billing address". It's OK. But when a customer don't have a billing address (guest, for example), then a default address should be used. In your case you did not enter a default address on the tax settings page. That could be fine. But you had "TaxSettings.DefaultTaxAddressId" set to some non-existing address identifier. That's why a system tried to load this address each time when calculating tax. I had several hundreds of SQL requests per HTTP request. I just entered a new default address and clicked "Save" (or you can set this setting to "0").

2. Discounts assigned to category could really slow down the system. I deleted your "30percent" and "Birthday20" discounts (replaced them with some other discount types)

Once it's done the page load time dropped from 15 seconds to 1 second (+ changeset described below)

I also highly recommend to apply changeset 48664fc80e76 (found this optimization after paying with your backup. thanks a lot). I have also updated the official 3.00 packages. So if you do not want to manually apply the fix, then just re-download the package.

Conclusion: everything works very fast if it's properly configured