1

I am attempting to work out my own delivery/collection slot setup.

Each delivery 'slot' is its own 'commerce product,' 10 x 1 hour slots per day for 10 days - 100 slots to span 10 days. Pick a slot and add it to the cart.

For the year I think there is around 4000 variants in one spreadsheet which i can import with feeds - so I have all the raw 'product data.'

Only thing is when I create a view of the 100 products it seems to get bogged down and takes ages to load - sorry for being non-technical.

Below is a screenshot of what I have and would like to achieve, how can I display my products as below but rapido! Attached screengrab

5
  • loading 100 items with a view should'nt be too resource demanding.Are you sure you don't have debugging tools enabled, which take a lot of resources? Commented Mar 22, 2016 at 16:44
  • Sadly no debugging, & whilst I am here, its just a simple content type with 7 fields: sku,title,date,slot,price,stock& status. PHP memory limit and time also have be increased.
    – Kleptonite
    Commented Mar 22, 2016 at 16:50
  • but why make a product for every day? As I see all the timeslot's are the same for every day, can't you just make 7 different products and add a date field to the line-item type? Commented Mar 22, 2016 at 17:02
  • The timeslots are the same, but the 'stock' allocated to each slot can and will vary - Sunday may have zero stock against all slots - no delivery/closed whilst Friday could have an extra driver and double the slot stock per hour.
    – Kleptonite
    Commented Mar 22, 2016 at 17:22
  • Sounds abnormal that it should take so long. Inspect the raw SQL and look at the database. Perhaps you could improve things by manually adding indexes to the fields involved in the joins and filters. Commented Mar 23, 2016 at 5:21

2 Answers 2

0

As the commenters above indicate, there's nothing in particular that should be causing this slowdown. You'll want to look into what might be happening during the render phase of your View and see if some Views query caching and / or render caching might help. The challenge, of course, would be preventing double bookings of fully utilized time slots - but maybe you could easily invalidate the cache in those cases.

If anything is causing the slowdown, it could be price calculation across 100 products happening multiple times per pageload. Commerce by default runs price calculation to determine if an Add to Cart button should be enabled or disabled and also to display the calculated price to render on the product page. That shouldn't be coming into play if you're just rendering product entities directly - typically you'd only see that on the product display node, and you could easily prevent it by editing the Views field to simple display the price as loaded.

To check out what's happening w/ price calculation, you can simply enable the Rules log and see if it's firing off a bunch of rules and then figure out how to disable it. I think Views caching with some smart invalidation as products are purchased is the right thing.

2
  • This is not a commerce issue... somethings wrong with my pc. It works fine on backup pc. Hey - thanks for taking the time to reply Ryan - all the best!
    – Kleptonite
    Commented Mar 23, 2016 at 18:05
  • My pleasure! Weird that it'd be a PC issue, but glad you got it isolated. : ) Commented Mar 24, 2016 at 19:55
0

Have you tried to use Views Load More or Views Infinite Scroll modules? these will create an Ajax request to load more content on demand instead of loading mass number of items at page load.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.