configurable custom products with > 50 options fail

Issue #1178 open
hux created an issue

We have a product that has 8 possible slots on it of which each of those slots could be any 10 different items.

Everything seems to work up to about 5 option groups containing 10 items per group, but once we try to add a 6th option group, apache/mod_wsgi and/or the devserver skyrocket their usage and never spit out any real error, nor does mysql report anything.

STEPS TO REPRODUCE:
(Using Django 1.1.2 and satchmo trunk)
Create a clean store, create a single product. Then create 10 optiongroups, containing 10 option items in each and then using the configurable product, assign 6 or more optiongroups to the one product and then try to view the product on the live site.

Please let me know if attaching the stack trace dumps would be of any assistance. I am happy to help debug this and hopefully fix this issue, but I'm not sure exactly where to start.

Comments (16)

  1. Former user Account Deleted

    It doesn't ever give a traceback. The apache process just hangs, and I even let it sit for a solid hour and it never completes nor gives any information. Same experience with the devserver.

  2. Tay Ray Chuan

    The stack trace is really very very heavy and it's hard to pick out the real problem.

    A traceback would be more helpful.

    If I read your original post correctly, this problem is also experienced on the dev server - if that's the case,

    - run the dev server - hit the admin page - add the 5 option groups - before adding the sixth, problematic one, note the dev server instance' output - after adding the sixth one and clicking submit, your server instance should now be stuck - after, say, 10 seconds, at the server console, kill the instance with Ctrl-C

    You should get a nice Python-like traceback.

    If possible, try varying the time before killing the instance.

  3. Tay Ray Chuan

    Sorry about that, I was too used to Markdown. Here are the instructions, re-formatted:

    • run the dev server
    • hit the admin page
    • add the 5 option groups
    • before adding the sixth, problematic one, note the dev server instance' output
    • after adding the sixth one and clicking submit, your server instance should now be stuck
    • after, say, 10 seconds, at the server console, kill the instance with Ctrl-C
  4. hux reporter

    The issue does not occur when the option group is created. The issues only surfaces when trying to view the product page on the site. Following your instructions, but then going to the product page, does not print anything to the satchmo.log nor to the devserver console -- including the GET request.

  5. hux reporter

    I was just able to get this in the satchmo.log file during the time the devserver is locked up:

    Sun, 18 Jul 2010 10:39:18 root DEBUG subtypes = ('CustomProduct',)

  6. hux reporter

    Has anyone been able to verify and reproduce this? Every time I try on any random system it does this, but maybe I am missing something?

  7. Chris Moffitt repo owner

    I think this may be an issue of just too many products. If my math is correct, 6 options times 10 choices each would yield thousands of products. Is that really what you want? I suspect it's just too big a query to return and things just time out.

  8. hux reporter

    It isn't product variations that we are doing. Just product options/optiongroups. It shouldn't be any more complex than haveing 8 t-shirts on a page, all with 10 size choices.

    Am I mis-understanding how to properly accomplish our goal? Originally we considered product variations, but then saw what it was doing to the sql queries. It seemed like moving to Options/OptionGroups was the proper way to do what we wanted.

    Thank you for all your help.

  9. hux reporter

    I was able to create a series of functions to facilitate gathering the Options and link them together in the manner I need for the project, without the same never-ending loop results from using get_valid_options().

    I will a post the finished version code and a link to our live store upon full completion in case someone else needs a similar setup in their store.

    Thank you all for looking into this and for creating such an amazing web store system.

    Sincerely,

    hux

  10. Former user Account Deleted

    I need to focus on some other aspects of this site and get the system online. Hopefully by mid-September, I will have the opportunity to publish this code (after some refactoring). In the meantime, if anyone else encounters the need for something similar to what I have mentioned here, just send me a /msg on bitbucket and I'll be happy to answer any questions and share some code snippits.

  11. scrapper

    hello friends,

    I think i have some information on to that. I do get on big database actions (which can last very long > 1h) after about 1Minute a 504 Gateway Time-out (running NGINX to serve static data in front of Apache with mod_wsgi). But the truth is the database queries work out fine. if i run

    colortail -f satchmo.log

    i do see how satchmo is slowly doing its work.

    So the question is, what is the proper way to tell NGINX mod_wsgi Apache2 combination to wait for the end of the background action?

    As example, yesterday night i turned of my computer. And today i restarted firefox and the "504 Gateway Time-out" is gone and the whole site gets presented fine.

    When does this happen to me? Well, by example i do have a lot of products in my shop, so when i click "Edit Invetory" in admin area this lasts long and will end up in "504 Gateway Time-out".

    Maybe the pros of us, Chris, Tay, Haynekcer, Bruce, can help us noobs out of this with a little hint? ;-)

    greetings

    sc

  12. Log in to comment