Developer forum

Hi Shiwanka

You can see from the timings that on the actual search 70ms (80-10) is used just to do facets. It is not a lot, but indicates that you either have a lot of facets or some facets with many options. So by removing one of those or replace it with a group facet if possible is an option.

The longest amount of time is after the search - getting the products out of the database.

The index returns autoids and they are used for DB lookup - that should be really fast unless there is a problem with the database index on the products table - you can try to rebuild the index (and check that it has not gone).

My guess is that you probably have something going on in a notification subscriber - these 2 are fired and is part of the 687ms execution time.

Notifications.Ecommerce.Querying.AfterQuery and Notifications.Ecommerce.Querying.BeforeQueryDatabase

Do you have any of these?

BR Nicolai

Hi Shiwanka

You can see from the timings that on the actual search 70ms (80-10) is used just to do facets. It is not a lot, but indicates that you either have a lot of facets or some facets with many options. So by removing one of those or replace it with a group facet if possible is an option.

The longest amount of time is after the search - getting the products out of the database.

The index returns autoids and they are used for DB lookup - that should be really fast unless there is a problem with the database index on the products table - you can try to rebuild the index (and check that it has not gone).

My guess is that you probably have something going on in a notification subscriber - these 2 are fired and is part of the 687ms execution time.

Notifications.Ecommerce.Querying.AfterQuery and Notifications.Ecommerce.Querying.BeforeQueryDatabase

Do you have any of these?

BR Nicolai

HI Nicolai

We don't have Any Notifications firing at the list load and I have rebuild all indexes and repositories.

we have currently 14k items and this could grow to 200k with in 6months. that's why I am more concerned about the list performance.

Here is the URL: https://bit.ly/3pEJuaK

Yeah, I can see that...

The search returns product autoids and use them to query the database. That should be really fast - so this could indicate that you have a missing database index or something mis configured for that field.

Do you have these db indexes?

If not we need to get a profiler on this to see what is going on - we need a copy that service desk can look into.

BR Nicolai

HI Nicolai

yes, we do have the same indexes

I will send db backup to service desk

Thanks

Shiwanka

ok - thanks for the update. Try right clicking the Indexes folder and rebuild the index. Just to be sure.

One finding:

These templates are based on Rapdio - it loads the product list and then calls the feed (&feed=true) to get the product data in json for the rendering.

For this to work, the tag @GetValue("DoNotRenderProductListTemplate") has to be in your ProductList.cshtml template. That tag ensures that the product list does not render in the initial load but only on the feed load.

By adding that tag to the end of your template, you will remove the problem above from initial load. That will make the page almost twice as fast.

Then the feed it self is also slow - products/women/accessories/watches?feed=true&pagesize=12&pagenum=1&minprice=0&maxprice=10000&SortBy=NameForSort&SortOrder=ASC&debug=true

That is the same issue - that page has to be debugged.

Hi Nicolai

tag @GetValue("DoNotRenderProductListTemplate"), this makes real difference to initial load time

but still feed debug gives this output

any clue