Hello.
I've been testing the module to see if the overselling problem (which has been an issue for Drupal modules in the past) is an issue with Commerce/Commerce Stock.
To test I've written a JMeter test script. I've been sending 50 threads (users), with 20s ramp up period, to a local install, checking out with the example payment method, setting 10 items as in stock - I am typically finding it will sell around 30 item, and the stock count after the test script has run will be between -1 and 4. I've tested with commerce stock 7.x-2.0-alpha2, and 7.x-2.x-dev, the results are the same.
I see this as two different (but related) problems:
1) The stock count becomes out of sync with the number of items sold - it is selling 30 items, and the stock count is only decreased by 6-11.
2) Once the stock hits 0, it still sells items if the payment is already in process.
It is likely that different problems will be found with different payment gateways, and the test script will need to be modified to test different payment gateways.
I've attached the test script here - to use it you'll need to download JMeter (http://jmeter.apache.org/). In the User Defined Variable section at the top of the test script you'll be able to define the product URL/ID, the site URL, and optionally a port number. You can also change the number threads and the ramp up period under the Commerce Stock Overselling Test Thread options. The setting in the script demonstrate the problem well on my machine, but may need to be tweaked, depending on how powerful your machine is - if I change the ramp up period to 10s, it hardly oversells at all, as it responds 500 to most of the requests, and if I change it to 30s, it oversells less as there are less collisions.
Any ideas?
Thanks,
Chris.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | commerce_stock_overselling_test.jmx_.zip | 3.2 KB | __cj |
Comments
Comment #1
__cj commentedThe test script wasn't attached above, as .jmx files are rejected, its zipped up and attached here.
Chris.
Comment #2
guy_schneerson commentedHi @chris_UK,
Thanks for the information and the test script i am sure it would be very useful and i will try and investigate this at some point.
My opinion on this is that the only sure way to not oversell is to reserve stock before payment is made using a transactional system so basically
Using the current process:
1) Check stock
2) Make payment
3) Decrement stock on successful payment / completion
On a busy site multiple orders can go past 1 while 2 is taking place especially if payment is made of site.
Transactional reservation system:
1) Check and reserve stock
2) Make payment
3) Decrement stock on successful payment / completion or return it on failure
In this system user cant get to 2 if no stock is available .
A transactional reservation system is not easy to achieve and it has many use cases and crossover with other transactional use cases like multiple stock locations (buckets)
I am hopping to position myself so I get interesting and challenging stock related commerce work and hopefully will get an opportunity to tackle this challenges in the future.
Currently on busy sites we agree with a client on a minimum stock level (easy to set up with stock v2) and this handles most cases.
Comment #3
__cj commentedHi,
Thanks for the quick reply. A minimum stock level approach although no doubt useful in some cases, will not fit all use cases.
There is a danger that by just reserving the stock at the beginning of the process you just move the problem - instead of selling too many items, you reserve too many items - having said this I do think you right - it maybe part of the answer as part of the wider changes to the module.
I also think perhaps a DB lock (http://api.drupal.org/api/drupal/includes!lock.inc/group/lock/7) could be part of a solution, to stop a second php thread selling (or reserving) the same item of stock that the first php thread is selling?
I may have some time to look into the problem over the next few weeks.
Chris.
Comment #4
guy_schneerson commentedHi @chris_UK yes it is a complex issue but the only way to guaranty 100% stock availability that's why some systems like allocated sits ticket give you limited time to complete the checkout as the ticket is pre-allocated to you and unavailable to others.
Their is no easy solution but hopefully the stock module will eventually be sufficiently flexible to support such solutions.
Comment #5
pjcdawkins commentedI have started work on this problem in a module called Commerce Stock Reserve. Please have a look and see if it meets your needs.