X-Cart warning

[zen]

Regarding Andrew's announcement (http://forums.dathorn.com/showthread.php?t=195) that X-Cart has been causing server performance issues in some cases, are there any recommendations to proactively address this? One of my customers is adamant about using it and as far as I know it has been fine for a couple of years now except for some table errors that were happening last week (which a repair fixed). I am happy to do proactive maintenance to avoid any issues, but not sure what I can really do other than regular db checks and repairs.

Thoughts?

[felipe808]

Xcart problems

If you look at variables under phpmyadmin, there are a whole lot of RED highlighted issues with descriptions that advise doing something...like scripts not using keys properly...is that just xcart doing that?

I sent this "problem" to the Xcart team to see what they say.

I'm running an older version of Xcart and I had it modified by an independent. I wonder if it is my xcart that is causing the problem. However, fortuantely or unfortunately, I don't get many visits on my xcart, perhaps 10 or 20 per day so could that little amount of action be causing the problems?

It goes without saying I don't want to be suspended.

Any comments appreciated. Thanks.

[AndrewT]

The problem is with the code itself and the amount of MySQL queries that it generates. Reparing databases and things like that is not going to be of much help.

[crunch42]

What about the HTML catalog option?

X-cart has a "generate HTML catalog" feature which generates a static version of the product catalog. Perhaps doing this would remove the MySQL load as far as people viewing the catalog goes. The MySQL calls would return whenever an admin modifies product listings, and whenever a shopper logs in, adds something to the cart and checks out, since these functions are not part of the generated HTML catalog, but these latter things make up a minority of page views.

I'm sure that enabling the HTML catalog would drastically reduce the overall MySQL load. However, it may be that the MySQL load during non-catalog related page views would still cause excessive spikes. It would be interesting to do a test to see, but of course, who has the time?

[felipe808]

Xcart Engineer response

This is what they tell me after explaining Andrew's assertion:

"Actually, moving images to the file system really increases the speed of the system. If you keep images in the database on MySQL server, each time you turn to the image, that's a separate request to the server, with PHP going to receive the whole image from the database. When images are kept in the file system, only pathes to images are received. That is why it really improves the performance and reduces the traffic."

What do you all think about that? The problem with these guys is language (English is not their first); it is hard for them to get the point at times. However, here they are talking about speed and "reducing traffic".

BTW: I have the HTLM cataloge running and update it and drop the old ones with any changes.

[felipe808]

X-Cart REcommendations continued from FAQ

There are several options that may help you to speed up site. Try them out first.
1. Move images from database to file system: admin zone -> ‘Images location’ (‘Store images in’, choose ‘File system’)
After that modify original .htaccess file (in /files directory): change the code to

<FilesMatch "\.(gif|jpe?g|png|GIF|JPE?G|PNG|)$">
Allow from all
</FilesMatch>
Deny from all

2. Toggle off atracking statistics

For v3.4.x:

in the customer/auth.php file, make the line

include "../include/atracking.php";

as follows:

#include "../include/atracking.php";

For v3.5.x and higher:

the statistics is disabled via admin zone, 'General settings':
uncheck 'Enable tracking statistics gathering' field.

3. Then clean statistic tables in the admin back-end of x-cart: ‘Summary’ page - > ‘Statistics clearing’

4. Execute the following sql query for each x-cart table

OPTIMIZE TABLE <table_name>;

where replace <table_name> with the name of a table. You will find the list of x-cart tables using the next sql query:

SHOW TABLES;

5. (optional) You may try to put the following lines in the php.ini file:

output_handler =
zlib.output_compression = On
zlib.output_compression_level = 1


You can put any figure in the compression level between -1 and 9, just muck around and see what works best for your particular store.

Or if you are using Apache server and .htaccess files are enabled you may try to add

php_flag zlib.output_compression On

to the .htaccess in the store root.

6. (optional) You can install Zend Optimizer (http://zend.com/store/products/zend-optimizer.php)

7. (optional) You may ask your hosting administrators to install mod_deflate (Apache 2.0.x) or mod_gzip (Apache 1.3.x).

8. (optional) Search engines may crawl your site and cause a performance degradation. You may slow down the robots crawling your site by adding the following line into robots.txt file (in the root of your web site):

User-Agent: *
Crawl-Delay: 10


If this doesn't work, there's one more variant - to order our optimization service. It requires special investigation to find out the exact reason. Developers will inspect the store carefully, determine the reason of the site's slow perfomance and provide you with possible solutions. If you are interested in it, post the request to the message board.

[ergo]

i have a custom e- commerce solution that generates no more than 9-15 queries per page.

if anyone is interested drop me a line :]