Forum Replies Created

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • in reply to: eCommerce Importer memory problems #8960
    jlarysz
    Participant

    The URL in step three was corrupted too. It’s the URL of your website followed by the filename “phpinfo.php”

    in reply to: eCommerce Importer memory problems #8959
    jlarysz
    Participant

    Some text was lost. The one line in phpinfo.php reads” phpinfo();”

    in reply to: eCommerce Importer memory problems #8958
    jlarysz
    Participant

    To change php memory and execution time settings:

    1: Write yourself a small php script that reads:

    2: Save it at the top level of your web site as “phpinfo.php”

    3: Run it by going to address http:///phpinfo.php

    4: Look a few lines down; it will tell you exactly where your “php.ini” file is. Open that file in an editor, such as notepad.

    5: Look for a property “max_execution_time”. Set it to something very big, e.g.
    max_execution_time = 90000 or bigger – it’s your server so it doesn’t matter.

    6: Do the same for “max_input_time” – there a bug somewhere such that the input time is sometimes looked at instead of the execution time. e.g. max_input_time = 90000

    7: Look for property “memory_limit”. Set this to something big too. e.g.
    memory_limit = 256M Don’t go with more than half your installed memory.

    8: restart your Apache server. Run “phpinfo.php” again and look for these parameters. You should see your new values in the report page.

    in reply to: eCommerce Importer memory problems #8954
    jlarysz
    Participant

    Hi Paul:

    Are you sure it’s a memory problem? I had that, rehosted with a more generous service, and hit the next issue, which looked pretty similar. This time the error came from the php script execution time limit, which was way too small to handle the generation of all the thumbnails that ecommerce wants. I blew past this by hacking the code – never a good idea but like you, I was stuck. I set up an option that did everything the standard importer did when importing a product with images, with the images referenced in CSV columns, but without actually generating the thumbnails. Instead, it generates a file with a list of the thumbnails needed. I then use that file with a little php code and ImageMagik to generate the thumbnails on my own computers and upload them.

    If you can import a small number of products – say 20 or so, then it’s execution time and not memory that’s blocking you.

    It’s a little messy and not my proudest moment, but like you I was (and still am) stuck. I can readily import batches of over 1000 products in the 60-second php execution time I’m allowed; I’m nervous but happy.

    If you have any coding experience at all I’ll send you my code, but IT’S A HACK – sooner or later Michael has to take this one up properly. If you are not technical you might find this worse that keeping beating up on Michael.

    in reply to: Web Site Performance #8849
    jlarysz
    Participant

    Here’s my interpretation of the problem.

    eCommerce generates several thumbnails when a product is uploaded. You specify a primary thumbnail – say a-thumbnail.jpg. According to how you have set up your site, eCommerce knows that it will need thumbnails of sizes (for example) of 31px X 31px, 38px X 38px, 148px X 148px, and so on. The site could generate these dynamically when the thumbnail is called up, and this is the fallback position. However, to avoid this, eCommerce generates thumbnails as part of the upload process. It names these a-thumbnail-31×31.jpg, a-thumbnail-38×38.jpg, a-thumbnail-148×148.jpg – you see the pattern. I think these are recorded in the database, but I’m not sure. What I am sure of is that even if these files exist, eCommerce doesn’t always use them. One circumstance is when using images that come from a Nikon camera. Some better Nikons names image files as X – for example, 311X2000.jpg. I think that eCommerce is interpreting the file basename as an image size and thus screwing up. I put a kludge into eCommerce in the code that works all this out so that there is a final check on whether an appropriate thumbnail file exists, and if it does my patch forces the code to use it. It works for my site but I didn’t generalize the file location part, it was getting too hard to be worth it. Doing this precludes ever upgrading eCommerce again unless eCommerce fixes it of course – it’s a rotten way to do things but it’s all that left to me.

    I might be wrong in my reading here. Does anyone else have a better idea?

    I don’t know how to put a ticket into ecommerce development – who owns that thing anyway?

    in reply to: eCommerce Importer memory problems #8747
    jlarysz
    Participant

    No, I don’t use these at all. I will give it a try though, next time I import.

    in reply to: eCommerce Importer memory problems #8745
    jlarysz
    Participant

    Not yet. What measurements do you mean? I haven’t dealt this them before.

    in reply to: eCommerce Importer memory problems #8743
    jlarysz
    Participant

    Well, I finally concluded that I wasn’t having memory problems on my hosting service any more – I was having execution time limits being hit and that the message was just a tad unfriendly. There was no way around this – I had already re hosted to beat the memory constraint. I’m ashamed to admit that I hacked the code and set up another import option – the code runs exactly as if images were being imported and thumbnails generated but instead of actually generating thumbnails, the details of what is needed are written to a file and I generate thumbnails separately on a development machine that I own and upload them to the internet host. I think my execution time limit is around 60 seconds; I can import at least 950 products this way at one pass. I’ll try a larger import when I have one ready.

Viewing 8 posts - 1 through 8 (of 8 total)