Make the module less process consuming
Vuds - July 9, 2009 - 00:30
| Project: | Ubercart Out of stock Notification |
| Version: | 5.x-1.5 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
I'm having a "problem" with this module. My site is hosted at MediaTemple and there I can get a report of performance like the one attached.
As we can see, the callback to query is the first position in GPU consumer. The problem I see is that everytime a user sees a product, the system consults its disponibility, and the query for it uses COUNT, which we know it is very resource consuming. When I have too many users on it browsing through products, the server really slows down.
My suggestion is to make use of information putting it on cache to avoid overload MySQL with too much slow queries. It could be renovated when the user completes checkout or paying.
Thanks for attention!
| Attachment | Size |
|---|---|
| uc_out_of_stock_problem.jpg | 96.56 KB |
#1
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.=
#2
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.
#3
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.
#4
Is this an issue with the D6.x version as well...?
#5
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?
#6
@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.
#7
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.
#8
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