I *may* be able to get a stripped-down version of what I've programmed as an example, but there'd be some work required to add all the extra nop stuff onto it (e.g I've removed store mapping & ACL checks)
I'd also have to do it in work hours which may be tricky, but I shall give it a shot. It'll be, basically unifying catalog + manufacturer page, and resoling URLs in the way of /[manufacturer], /[category], /[manufacturer]/[category] without using the GeneralPathRoute
Performance optimization needed - NOPCOMMERCE IS TOO SLOW !
Team Member
- 16616
- 155915
- 10/22/2008
- Armenia
sproaty wrote:
Hi Steven,
Sure. It would be great. Thanks
I *may* be able to get a stripped-down version of what I've programmed as an example, but there'd be some work required to add all the extra nop stuff onto it (e.g I've removed store mapping & ACL checks)
I'd also have to do it in work hours which may be tricky, but I shall give it a shot. It'll be, basically unifying catalog + manufacturer page, and resoling URLs in the way of /[manufacturer], /[category], /[manufacturer]/[category] without using the GeneralPathRoute
I'd also have to do it in work hours which may be tricky, but I shall give it a shot. It'll be, basically unifying catalog + manufacturer page, and resoling URLs in the way of /[manufacturer], /[category], /[manufacturer]/[category] without using the GeneralPathRoute
Hi Steven,
Sure. It would be great. Thanks
- 299
- 2752
- 5/15/2013
- United Kingdom
a.m. wrote:
Andey, could you explain a little bit more please, why is dying dinosaur.
I've chosen Fluent NHibernate as an alternative to EF because of so many issues with EF performance, and it's looks quite promising. So is any particular reasons to reject using NHibernate?
Thanks a lot!
P.S. I do not consider nHibernate as dying dinosaur
Andey, could you explain a little bit more please, why is dying dinosaur.
I've chosen Fluent NHibernate as an alternative to EF because of so many issues with EF performance, and it's looks quite promising. So is any particular reasons to reject using NHibernate?
Thanks a lot!
Team Member
- 16616
- 155915
- 10/22/2008
- Armenia
kaunuk wrote:
It was a type. I DO consider nHibernate as dying dinosaur
kaunuk wrote:
It's described above. I think so =))
Furthermore, let me quote myself from this post (replaced Dapper with nHibernate):
The second issue is that almost every ASP.NET developer is familiar with EF. And I presume that only 2-3% of them worked with nHibernate. Of course, we can talk about leaning curve and so on. But it can seriously effect product popularity
P.S. I do not consider nHibernate as dying dinosaur
It was a type. I DO consider nHibernate as dying dinosaur
kaunuk wrote:
So is any particular reasons to reject using NHibernate?
It's described above. I think so =))
Furthermore, let me quote myself from this post (replaced Dapper with nHibernate):
The second issue is that almost every ASP.NET developer is familiar with EF. And I presume that only 2-3% of them worked with nHibernate. Of course, we can talk about leaning curve and so on. But it can seriously effect product popularity
- 17
- 101
- 4/25/2013
- India
Nopcommerce is best for eCommerce website.
I was working charm with less data.
But now i am facing issue with speed, I have 2000+ category in my website.
My admin panel is very slow, my product page takes 50 sec to load.
Does any one have solution for this?
I think this is due to
model.AvailableCategories.Add(new SelectListItem() { Text = _localizationService.GetResource("Admin.Common.All"), Value = "0" });
var categories = _categoryService.GetAllCategories(showHidden: true);
foreach (var c in categories)
model.AvailableCategories.Add(new SelectListItem() { Text = c.GetFormattedBreadCrumb(categories), Value = c.Id.ToString() });
as it loads all 2000+ categoy and for each 2000+ category we call c.GetFormattedBreadCrumb(categories) so it will call more queries.
can any one suggest me good solution?
My solution convert category dropdown to autocomplete text box , So as user type in category will be loaded.
Do you have better solution ?
I was working charm with less data.
But now i am facing issue with speed, I have 2000+ category in my website.
My admin panel is very slow, my product page takes 50 sec to load.
Does any one have solution for this?
I think this is due to
model.AvailableCategories.Add(new SelectListItem() { Text = _localizationService.GetResource("Admin.Common.All"), Value = "0" });
var categories = _categoryService.GetAllCategories(showHidden: true);
foreach (var c in categories)
model.AvailableCategories.Add(new SelectListItem() { Text = c.GetFormattedBreadCrumb(categories), Value = c.Id.ToString() });
as it loads all 2000+ categoy and for each 2000+ category we call c.GetFormattedBreadCrumb(categories) so it will call more queries.
can any one suggest me good solution?
My solution convert category dropdown to autocomplete text box , So as user type in category will be loaded.
Do you have better solution ?
- 95
- 709
- 11/19/2013
- United Kingdom
Little update on my post -- again, specific to my use case, but perhaps a worthy demonstration:
sproaty wrote:
I went ahead and implemented these "Skinny" classes inside my service for retrieving products for "catalog" page and ran a few performance tests (refreshed page first to warm cache, then refresh 5 times and check query time using Glimpe's EF Profiler" tab:
: (service method I'm using instead of "SearchProducts". Total LINQ query; it does far less query checks than the above mentioned stored procedure call; and also eagerly loads every product's manufacturer (which I've changed to be a Product has one manufacturer instead of product has many)
Using SearchProducts at first took about 250ms, and then n* calls to retrieve the Manufacturer as eager loading isn't possible through the stored procedure way. So then, one query + 15x 2ms queries to show 15 products.
Then added another service method which eagerly loads manufacturers - took about 95ms on average. Returning
Before, returning a IEnumerable<Product>
Then I created a few "Skinny" classes for Product + Manufacturer and project my LINQ objects to these objects, instead of the "full-blown" domain models, seeing as I don't use all the Product information here.
This change brough the method call down to 20ms on average. Now my pages are getting ridiculously quick -- ~200ms for the first time load and then down to 50ms as generated links are cached. Awesome!!
I've yet to check how this has affected memory usage; though I suspect by not much.
sproaty wrote:
I'm looking into reducing the memory footprint of my site, too (veering off quite drastically from the Nop.Web site) and am looking into potentially reducing caching for many services, as with the way I'm writing the code then there won't be more than 1 call to the same service. Instead I'm creating more granular service methods that do joins across entities needed and returns fully-populated domain objects, so no need to eager load.
Also for some pages I know will be traffic heavy and performance crucial, I'm changing custom service methods to return "skinny" objects, that I can use with automapper to map to ViewModels. If you look at a query generated in retrieving a Product, then it's bringing back ~40 columns, whereas I'm only using 6 or so. So at the service layer I'm projecting to a SkinnyProduct class that contains only what I need -- simplifies my code's intention when using the service, and also minimises the data that needs to fetched from the DB.
May knock a few mb from usage.
Also for some pages I know will be traffic heavy and performance crucial, I'm changing custom service methods to return "skinny" objects, that I can use with automapper to map to ViewModels. If you look at a query generated in retrieving a Product, then it's bringing back ~40 columns, whereas I'm only using 6 or so. So at the service layer I'm projecting to a SkinnyProduct class that contains only what I need -- simplifies my code's intention when using the service, and also minimises the data that needs to fetched from the DB.
May knock a few mb from usage.
I went ahead and implemented these "Skinny" classes inside my service for retrieving products for "catalog" page and ran a few performance tests (refreshed page first to warm cache, then refresh 5 times and check query time using Glimpe's EF Profiler" tab:
: (service method I'm using instead of "SearchProducts". Total LINQ query; it does far less query checks than the above mentioned stored procedure call; and also eagerly loads every product's manufacturer (which I've changed to be a Product has one manufacturer instead of product has many)
Using SearchProducts at first took about 250ms, and then n* calls to retrieve the Manufacturer as eager loading isn't possible through the stored procedure way. So then, one query + 15x 2ms queries to show 15 products.
Then added another service method which eagerly loads manufacturers - took about 95ms on average. Returning
Before, returning a IEnumerable<Product>
Then I created a few "Skinny" classes for Product + Manufacturer and project my LINQ objects to these objects, instead of the "full-blown" domain models, seeing as I don't use all the Product information here.
This change brough the method call down to 20ms on average. Now my pages are getting ridiculously quick -- ~200ms for the first time load and then down to 50ms as generated links are cached. Awesome!!
I've yet to check how this has affected memory usage; though I suspect by not much.
Team Member
- 16616
- 155915
- 10/22/2008
- Armenia
govi2010 wrote:
Previously we loaded breadcrumb using several queries. First we loaded root categories, then we load child subcategories for each category and so on. That was slow. Now we load them for one query. It's much faster. Also note that c.GetFormattedBreadCrumb(categories) WON'T call more queries because all categories are already loaded
...
as it loads all 2000+ categoy and for each 2000+ category we call c.GetFormattedBreadCrumb(categories) so it will call more queries.
...
as it loads all 2000+ categoy and for each 2000+ category we call c.GetFormattedBreadCrumb(categories) so it will call more queries.
...
Previously we loaded breadcrumb using several queries. First we loaded root categories, then we load child subcategories for each category and so on. That was slow. Now we load them for one query. It's much faster. Also note that c.GetFormattedBreadCrumb(categories) WON'T call more queries because all categories are already loaded
- 17
- 101
- 4/25/2013
- India
Thank for replay.
I am mvc developer, but new to nopCommerce.
I like project architecture.
I have 30,000+ product with 2000+ categories.
and my website is slow. for less data it work fine. but currently in admin panel my categorylist page takes 9 sec time and product page takes 50sec time.
I am mvc developer, but new to nopCommerce.
I like project architecture.
I have 30,000+ product with 2000+ categories.
and my website is slow. for less data it work fine. but currently in admin panel my categorylist page takes 9 sec time and product page takes 50sec time.
Team Member
- 16616
- 155915
- 10/22/2008
- Armenia
govi2010 wrote:
I see now. This performance issue existed in 3.20 (and below) but was fixed in 3.30
Let me also let you know that i am using 3.2 version of nopCommerce. Can anyone tell me how to import/export category in nopcommerce. I want to test my 2000+ category in new 3.3 version of nopCommerce.
I see now. This performance issue existed in 3.20 (and below) but was fixed in 3.30