Caching the countdown time data

Can you share some more info about what is slow? I suspect a single page with one item (possibly with variations) isn’t slow. Is the issue on shop pages with lots of items or maybe a product page that has “You might also be interested in” type products displayed.

I can think of a couple possibilities to speed it up but I suspect all of them will take a bit of time to implement.

I’m thinking about caching the per product data and using that data if available for archive pages (ie: shop pages) but the single type pages (individual products) would always refresh the data to make sure it is current.

The Webgrind profiling done by our hosting company indicated the line 998 in the class-woocommerce-cart-stock-reducer.php file as a cause for the slow page loading. They recommended that a good solution would be to perhaps implement some kind of a transient get/set feature for that part of the code. Maybe so that one could set the time for the transient caching in the plugin options.

And it also seems that disabling the plugin helps the archive pages load a lot quicker. With the individual product pages the load speed is good also with the plugin enabled.

It certainly makes sense that it would slow down with large numbes of products, there will be queries for every item. I’ll add it to my list of things to work on.

Excellent, that would be great. Thanks James!

Would there be any harm if the plugin was selectively disabled on product archive pages and have it only load in product pages, shopping cart and checkout? And if it doesn’t cause any harm how could this be achieved? Is there some hookable filter that could be used to disable the plugin in the archive page? I’ve been looking for some tutorials on how to selectively disable plugins and/or plugin filters through code but haven’t tried them yet.

Anyway the difference between having the plugin active/deactivated is quite big as you can see below. Hopefully this could be solved without us stopping the use of this plugin.

Plugin ‘woocommerce-cart-stock-reducer’ deactivated.
Success: Deactivated 1 of 1 plugins.
for i in {1..5} ; do curl -so /dev/null -w ” %{time_total}\n” -H “Pragma: no-cache” [product archive url]; sleep 1 ; done
2.154
1.719
1.722
1.729
1.832
Plugin ‘woocommerce-cart-stock-reducer’ activated.
Success: Activated 1 of 1 plugins.
for i in {1..5} ; do curl -so /dev/null -w ” %{time_total}\n” -H “Pragma: no-cache” [product archive url]; sleep 1 ; done
7.308
7.436
7.654
7.272
7.508

Dear James Golovich,

Unfortunately we experienced the same results with your plugin.
When it enabled it coz 4-5-6s latency for a latest WooCommerce site with 500+ products.

We love the functionality, but the performance issue is the worst what I ever seen.

Hope you could optimize your plugin performance bottleneck.

Cheers,
Crhis

Wow, that is terrible. I’d never settle for those kind of results ??

I’ve personally never tested with a large number of products, guess I need to generate a test bed.

I am curious from people with large shops. Do you happen to have a lot of people active all the time with items in their carts?

The slowest part with this is checking for each individual item in every cart, I could change the query so instead of looking for a specific item it just grabs all the data and caches it. I’ll have to test it out but I’m sure it will be significantly faster.

@tatutre I’ve never tried disabling a plugin on certain pages, seems like the wrong approach for most situations. I’d worry about items getting improperly added to a cart when added directly from a shop page.

I am curious from people with large shops. Do you happen to have a lot of people active all the time with items in their carts?

Nope, doesn’t need lot of people, I tried on a test IP address with the same result (I was the only customer as admin )

I think it happens coz of bigger database, but 500+ is not a big one. It should work with 5000+ too if everything is correct.

I hope it helps to find the way to repair ??

Best wishes,
Chris

Nope, doesn’t need lot of people, I tried on a test IP address with the same result (I was the only customer as admin )

I think it happens coz of bigger database, but 500+ is not a big one. It should work with 5000+ too if everything is correct.

That’s kind of what I figured. Most of the time there are small number of items in carts. The problem with the way I was doing it before is all carts are checked for each item individually. I’m switching over to loading and caching all the contents in the carts and then just searching that data for each item.

I’m switching over to loading and caching all the contents in the carts and then just searching that data for each item.

It sounds good, hopefully this way will dramatically improve the speed of your plugin!

Keep the good & hard work up! ??

I’ll waiting for your new release!

Cheers,
Chris

I used a few tutorials to build a mu-plugin that selectively disables the cart stock reducer on archive pages and some other pages. Mostly the cart stock reducer is now enabled only on product pages, cart and checkout. I’ve disabled the add to cart buttons on archive pages so the products can only be added to the cart through product page.

So far I haven’t seen any negative side effects. And now the page loads 5-6 seconds faster on product archive pages. However it would be nice if the performance could be improved without having to use this method. I wonder how the this feature is done in Prestashop because I’ve been told that there you have option to decide whether the stock is reserved/reduced at time of adding the product to cart or when order is done.

The mu-plugin code:

<?php

$request_uri = parse_url( $_SERVER['REQUEST_URI'], PHP_URL_PATH );
 
$is_admin = strpos( $request_uri, '/wp-admin/' );

// add filter in front pages only
if( false === $is_admin ){
	add_filter( 'option_active_plugins', 'selective_plugin_disabler' );
}

/**
 * Filters active plugins
 *
 * @param array   $plugins An array of active plugins.
 */
function selective_plugin_disabler( $plugins ){
	
	$plugins_not_needed = array();
	
	// selectively disabled plugins
	$current_url   = 'https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'] . '';

	if ( strstr( $current_url, '/categories/' ) ) {
		$plugins_not_needed = array('woocommerce-cart-stock-reducer/woocommerce-cart-stock-reducer.php');
	} else if ( strstr( $current_url, '/blog/' ) ) {
		$plugins_not_needed = array('woocommerce-cart-stock-reducer/woocommerce-cart-stock-reducer.php');
	} else if ( ($_SERVER['REQUEST_URI'] == '/')) {
		$plugins_not_needed = array('woocommerce-cart-stock-reducer/woocommerce-cart-stock-reducer.php');
	}
	
	
	foreach ( $plugins_not_needed as $plugin ) {
	$key = array_search( $plugin, $plugins );
	if ( false !== $key ) {
	unset( $plugins[ $key ] );
	}
	}

	return $plugins;
}

But anyway, just like Chris said. Keep up the good work. Hopefully you can come up with ways to improve the performance. I’m happy to help with testing.

• This reply was modified 7 years, 2 months ago by tatutre. Reason: removed reference to unnecessary other plugin

I’ve got changes completed, just need to work around a WooCommerce edge case before pushing the changes to github.

I’ve got changes completed, just need to work around a WooCommerce edge case before pushing the changes to github.

Great news! I’m so excited ??

I just pushed some major changes onto the github repository related to this issue. The method I started with earlier today was going to need more hacks upon the hacks already built so I changed the method completely.

In my testing with 5000 items (100 items per page) there is still a small overhead, but nothing compared to before. Definitely a noticeable general Woo slowdown with more items, but that’s not relevant here.

Previously (with this plugin and a generic setup) there would be 4 queries per item displayed, the queries are relatively fast it’s the overhead that adds up.

What I changed was pre-caching all of the cart/session info. Amazingly there is no interface with WC to access a cart/session for other than the currently active user.

I’ll do some further testing, one of these days I’ll try to find the time to build some integration tests and cut down on the manual testing.

I’ll do some further testing, one of these days I’ll try to find the time to build some integration tests and cut down on the manual testing.

I copied/created the new files/changes from github.
What I could say it is faster than it was, but need more changes to the best result.

Thank you for your effort and the hard work on it.