After having added about 200 items in the store it seems the size is getting to about 85 MBs now.
With adding 1 single product, 1.0-1.2 MB is added now and the database is using like 800,000 rows.
Also, the backend is getting noticably slower and slower (the frontend is doing ok).
At some point in time, the following message popped up:
Fatal error: Maximum execution time of 30 seconds exceeded in /home/user/domainame.tld/html/shop/lib/Zend/Db/Select.php on line 1101
The thing is, it takes about 30 seconds now to duplicate an item. There’s not much to it. Just some text and an attribute set of course.
Anyone with the same issue(s) and/or a solution to this?
I have a catalog of 4000 odd products and the total space shown by PhpMyAdmin for all tables is 189 MB of which it was interesting to note that
sto_dataflow_batch_import alone took up 141 MB.
But I see another problem when my catalog was of this size ... the search performance decreases exponentially .... particularly if the search results hits are more ...if a search keyword has a 100 hits, the search takes close to 30-40 sec !!!! that was pretty discouraging ... was wondering if attributes of all the 100 hits are being queried up and that is the reason this appears to degrade the performance ...but not sure .....discussing this in a separate thread anyway
I’ve been noticing the same thing. We have a filtered layer nav attribute called item_classification, which is based on an ever growing classification guide that can have a limitless number of classifications. As we test the item_classification with larger sets, it certainly does seem to draw alot of resources in various scenarios such as the search functionality. I do think that, like you suggested, the search query is loading all of the attributes, which is consuming alot of resources. Right now I think we’re trying our item_classification attribute with upwards of ~400 entries, on ~ 4200 products. I’ll have to double check though as we are no longer able to access that attribute via the admin - any attempts just stall. I understand that attributes can be excluded from search results, but since our item_classification attribute is a dynamically evolving attribute based on keyword research which is updated from search engine queries, we really want to see it included in the search results. Hopefully we can make progress in this area.
Fatal error: Maximum execution time of 30 seconds exceeded in /home/user/domainame.tld/html/shop/lib/Zend/Db/Select.php on line 1101
That’s telling me there’s memory issues. What kind of environment are you running in? If it’s a VPS or dedicated, how much RAM is allocated to either the VPS or server? Have you tried increasing the max_execution_time and/or memory_limit for PHP?
Yes, the limit has been set to128MB.
It is run in a VPS with about 512MB dedicated memory, only about 60 MB is used currently. All is maintained by ourselves.
max_execution_time limit is set to 30
php-cgi process is quite busy during duplication.
After about 40 seconds, the process fails. Displaying a different message (line differs).
Fatal error: Maximum execution time of 30 seconds exceeded in /home/user/domainname.tld/html/shop/lib/Zend/Db/Adapter/Abstract.php on line 887
These are the largest files. Only the first and second are bizar.
Actually, the number of products is about 160. The last 20 products added (without illustrations) have made the database catalogindex_eav grow from 85 to 123,5 MB.
I figured you were on a VPS. This is a recurring issue for a lot of people, they’re either getting blank pages or timeouts, all stemming from an environment with too little memory allocated.
What control panel are you using? If it’s cPanel, then already a lot of memory is being used by that, since it requires 256MB to even be installed on a system.
Have you tried disabling any unnecessary services to free up some room?
Yes, blank pages and timeouts indeed.
We use Parallels Containers. No Plesk, just plain Fedora as clean as possible, no unneeded packages.
There should be nothing wrong with a VPS, also the memory is more than sufficient since it can boost to over 4 GB.
But, what I have learned today is that the duplicate feature is causing all these troubles.
I have started using adding products without using the duplicate feature and this not only goes well, it is quicker than using the duplicate feature with the waiting period (2x ±30 seconds).
Also, after having added 30 products, the database growth was 1,0 MB and the rows (_eav) had grown from 10001912 to 1170459, this is quite different then before. Strangely enough this turned into 770.000 rows after adding a few more products.
So far it seems to be going ok, But the duplicate feature seems to be the cause of these troubles.
