Server resources - hosting problems - MySQL

Hello,

I am a host and a client using zen-cart is causing ongoing issues with very heavy server resource usage. It seems to be heavily MySQL based and causes a lot of sleeping processes on the server. Eventually this causes the server load to rise unacceptably.

I've found the version number in the database as 1.39g. This looks to be considerably older than the current version available for download.

Can anyone here advise if an upgrade will likely bring any major improvements to this issue.
I have noticed that the script also saves many many thousands of files in the cache folders, which consumes vast amounts of disk space causing my client problems. This seems disproportionate to the number of products on the store (approx 2000). I read that it is possible to change to a database caching system instead, but frankly given the existing MySQL issues, this does not seem like it would be helpful here.

I'd appreciate any advice on whether an upgrade is the path to take, or any other insights on configuration issues that may assist.

Thanks,
Kevin Martin
GM-Innovations.com

If the cache folder is filling up there is any issue with the cart, upgrading is an absolute must for security but isn't as simple as it may look, nor a fix for this problem.
Both of these items I would recommend speaking with a developer.
Can you send a copy of one of the recent cache files?

bislewl:

If the cache folder is filling up there is any issue with the cart, upgrading is an absolute must for security but isn't as simple as it may look, nor a fix for this problem.
Both of these items I would recommend speaking with a developer.
Can you send a copy of one of the recent cache files?

Thanks.

Yes, here is the full contents of a cache file from today:

File name/location:
www/store/cache/ssu/products/9937_en*

File contents:
2-48-carat-pear-shaped-unheated-blood-red-ruby-from-mozambique-p-9937

Does this mean anything interesting or useful?

As far as gettign a developer on board, that would be a decision for the site owner, my client. I'll draw his attention to this thread.

Thanks,
Kevin

While there may be issues with the single installation of zencart you refer to, we have 53 installations of zencart on one server - and have no problems.

Is your server up to the task of eCommerce? If not, maybe you should advise your client to host where servers have the capacity to handle these platforms.

can you send the contents of one of the files in the www/store/cache/
most recent would be most helpful.

Thanks again, bislewl. There are no files directly in the cache folder. Only the subfolder ssu which appears to contain the large number of files/folders.

-rw-r--r-- 1 starruby starruby 1104 Apr 29 2010 .htaccess
-rw-r--r-- 1 starruby starruby 1511 May 6 2005 index.php
drwxr-xr-x 6 nobody nobody 4096 Nov 17 19:35 ssu/

Does this provide any clues?

Thanks,
Kevin

To schoolboy,

Thanks for your advice but I am not new to this (hosting) and am very confident the server is more than powerful enough. We host sites on various mainstream ecommerce platforms, across numerous servers, but this is the only zencart issue that has arisen, so I feel quite sure it is a site specific issue.

The /ssu is not part of Zen Cart but I believe there is an SEO/rewrite add on that uses it ...

You might check with your client on if they are using something for that ...

"/ssu/" indicates yellow1912's Simple SEO URLs mod, which is no longer supported nor apparently compatible with v1.5.x (at least unless it gets updated).

If "Query Cache" is not installed, you may want to look at installing it (or upgrading to 1.5.1 which includes a modified version).

One of my client's sites was running into similar "complaints" from a hosting provider about using too many MySQL queries (yes, this was their complaint - not long running queries - but too many!). I installing the "Query Cache" plugin and enabling the Zen Cart caching mechanism to cut down on queries (and disabled tracking category/product views and who is online in Zen Cart).

I then made a phone call (and eventually got to one of the server admins) who looked at the average usage since the changes were made and confirmed the resource usage was "acceptable" and unflagged the account for high "resource" usage. The same admin also recommended adding "delays" to SQL insert / update statements when importing a large number of products and/or categories (common when doing bulk updates).

May not solve your issues, but something you can look into... or better yet, move to a hosting plan / provider who can handle a larger number of MySQL connections and queries.

I will reiterate what's been given for feedback:

1. The /cache/ssu/ folder is used by an addon, as described. Perhaps it is malfunctioning either by not doing any garbage collection or not re-using components it has cached. Either way, the first thing I'd suggest is disabling that addon. Of course that will cause the store's URLs to change, which may have SEO impact, so should be a temporary measure to simply aid in diagnosing ie: narrowing the pain symptoms to just that addon's effects.
   Periodically purging that ssu cache might be smart, but you might want to read up on what the implications of that may be. I'm not familiar with that addon's detailed inner workings.

2. Query Cache will reduce the number of "repeat" queries, simply by adding an internal cache of results of repeat query calls. If the MySQL server isn't already caching intelligently then this application-layer caching will help improve speed somewhat.

3. I will add that these FAQ articles, and the links therein, are valuable reads:
   http://www.zen-cart.com/content.php?63-how-do-i-speed-up-my-site
   http://www.zen-cart.com/content.php?262-webserver-tuning-tips

Thanks for your suggestions everyone. My client is going to contact the developer of the SSU plugin with whom he has had previous contact, and see if there is an issue with it or if it can be optimised/updated. Failing this, the articles in the previous reply give some very worthwhile specific suggestions for configuration and selective feature disabling that could be useful. And the Query Cache sounds hopeful too.

We will see where it all leads us.

Thanks.