Make the module less process consuming

Caching in this case might not be the best thing, as you will have a cache entry of each product for each visitor on the site, and eventually the whole idea of having a real time notification would be lost. But anyway, I'd think this is an important issue. I wonder if you can have time to follow this up and help by providing a patch that would increase performance? I rather try improving someway the logic than trying to cache information, although some kind of cache might work as well, but I have to take a look at that.

I am not so sure the COUNT() query is the problem there.

Something else that can be done is the ability to disable AJAX query and just leave the server side validation, in that case the logic will be executed only when an ADD TO CART product is added to the cart. This was something that was on my mind already.

Anyway, let's see what we can do.
a.=

I didn't realize the hit that this puts on the server, i removed it after 3 days of use. When there are 20 products on a page and 100 people browsing the catalog at a time it doesn't do very good things to the server.

I realize that this is an important issue, and I would appreciate any help in terms of finding a way to improve. I would try to make a proper look at it.

Is this an issue with the D6.x version as well...?

Just noting an idea I just come up while fixing other stuff. If somehow I can add the model information as a JS dictionary when the node is viewed, and then use that dictionary to query the server by model instead than by attributes, that could speed things up. Is anybody that's experiencing performance issues but still using the module? Just checking in case I implement this, I would need some help monitoring.

@Vuds: what about you?

@hanoii I've deactivated the module from my production site (couldn't take the hit of 120+ seconds between attribute selections), but I'd be happy to test changes on staging. I am on 6.x though.

Could there not be a global cache for the stock levels on the site, that is consulted by this script?
As the reporter stated this could be refreshed (or updated) when someone completes an order, and should significantly reduce db queries. I don't see any need for a per-user cache.

I agree, this modules makes my site run very slow on a slow MAMP installation, not even on a web server.

I found this thread, which provides a nice theming way to solve the problem that seems much less resource intensive.

http://www.ubercart.org/forum/support/4037/stock_level_product_page

Related to #657924: Option to disable the use of Javascript

duplicate/related: #738798: Excess Logging of Stock Queries in Recent Hits Log

The performance issue is terrible for me too: http://drupal.org/node/875044

Hello,

What about, as first step, adding an option to choose if you want stock control all over the shop or ONLY AT CHECKOUT PROCESS.

I think second option is a solution this issue, because now, most of CPU use happens while rendering catalog (one of my shop has about 700 products, listed in about 30 categories).

Another possibility is yours: "Something else that can be done is the ability to disable AJAX query and just leave the server side validation, in that case the logic will be executed only when an ADD TO CART product is added to the cart. This was something that was on my mind already." The problem for me is that your module semms not running with UC Ajax Cart module (I have not out of stock alert... but doesn't matter, because checkout or cart refresh validatons are OK).

@hanoii: I can help you monitoring these issue, as you ask for in #5

Regards

Here's a rework of the AJAX functionality that hits the server so hard for catalog/views pages. Instead of sending an AJAX call for each product on the page (which, in turn, requires one or more SQL queries) it collects them all up, does one AJAX post, and then updates all the forms based on their stock info. The drupal function tries to be smart and only do one SQL query for all the products being checked if there are no attributes to complicate things.

Will certainly review this, although I have a major reworking thought in place, actually a bit worked out but haven't had the time to make it a proper contribution. Basically my approach would not make any ajax call whatsoever, but rather add all the stock information on page load and then do all through local JS.

If you did it all in local JS then you would lose the ability for the stock notification to be accurate when caching is turned on for anonymous users, right? That's why, I imagine, it was an AJAX call in the first place, no?

subscribing - had to uninstall because it's too server intensive, but love the module.

Subscribing. I've also noted this, but still consider very useful the module.

Updating with a slightly updated patch that improves performance further by not making any AJAX calls if there are no products on the page. Any change on getting it into the 1.x branch?

Thanks jrust for patch #18
I got an error applying it "malformed patch at line 160", but after applied it manually (?!...) it seems to do the job, faster and less ressource consuming.

I'm trying to apply patch #18 too and got the same error of "malformed patch at line 160" , #19 would you show me how to apply it manually ??
Thanks a lot !

At the top of the file, you will find the filename to modify. Then minus sign indicate a line to remove and plus sign a line to add.

#18 works well for me :-) thanks.

I manually added #18 (got the same malformed error) and it seems to be working okay.

Here's an updated patch that doesn't give a malformed patch error.

I'm working on applying these improvements to my patches that update the module to Drupal 7 and Ubercart 3.0 as well. Check out this issue for more info on that work:

http://drupal.org/node/1201310

Added the performance changes to the proposed Drupal 7.x/UC 3.0 patches here:

http://drupal.org/node/1201310

Was not able to apply latest patch either (other than manually). Could you please attach patched versions of uc_out_of_stock.js and uc_out_of_stock.module (just in case to ensure that all went ok). Thanks.

Applied patch (if I were able to get it right) seems to do the job slightly faster and less resource consuming but does not resolve performance issues with product pages that includes attributes ...

Has anyone been able to resolve why out of stock check takes such a long time for products having attributes?

Patch doesn't apply to the latest dev.. can you please re-roll it? I might review it anyway or do something similar.

Attached is a patch against dev. It's mainly #24 with some small changes as I had to apply it manually. Seems to be working. I will now try it on a site with attributes and if it works, it's going soon into the dev version and into a new release.

Thanks @djflux, @jrust and @Vuds!

Left a console.log() inside the patch.