Performance Issues - Stopgap Solution

**nsabine** · 23 Jan 2007, 07:45 AM

I recently added a few products to my Zen Cart installation that have lots of attributes. Previously, I had not noticed any performance issues with the cart, but now I am intensely aware of it.

I own my own server: a brand new dual core, dual CPU Xeon w/ 3 GB RAM, and I know that the load average is typically 0. Performance should not be an issue.

Nonetheless, my attribute-laden products take between 50 and 60 seconds to show up. I have tuned the server to the best of my ability, and turned on DB caching.

Since 60 seconds is simply not acceptable, I have implemented a workaround using PEAR cache_lite. It was surprisingly easy to implement.

Note that this solution may not work for you, depending on how "dynamic" your site is.

First I installed PEAR cache_lite. I have root access, so this was easy. I think pear libraries can be included without root access, but I'm not an expert on that.

Code:

#> pear install cache_lite

then I opened up catalog/includes/templates/<my_template>/common/tpl_main_page.php
and found the lines:

Code:

<?php
 /**
  * prepares and displays center column
  *
  */

 require($body_code); ?>

I have a heavily customized installation, but it should be around line 120 or so.

I changed this area of the file to look like this:

Code:

<?php require_once('Cache/Lite/Output.php');
$options = array(
        'cacheDir' => '/tmp/',
        'lifeTime' => (60*60*24)
);

$cache = new Cache_Lite_Output($options);
if (isset($_GET['products_id']))  {
if (!($cache->start($_SERVER['REQUEST_URI']))) {
?>
<?php
 /**
  * prepares and displays center column
  *
  */

 require($body_code); ?>

<?php
  $cache->end();
}
} else {
 /**
  * prepares and displays center column
  *
  */

 require($body_code);
}
?>

I know, not pretty, but it works.

What this does is create a 24 hour cache for all pages where product_id is set. These are the product_info pages, i.e., the pages that display all the attributes.

I then set up a cron job to clear and regenerate the cache in the middle of the night.

The cron is not explicitly necessary, as the cache will automatically expire in 24 hours, but I never want a user to be faced with the 60 second delay as the page rebuilds. If you don't have access to cron, you may want to set your cache to never expire, and manage the cache manually.

clearcache.php

Code:

html>
<body>
<?php
require_once 'Cache/Lite.php';

$options = array('cacheDir' => '/tmp/');
$cache = new Cache_Lite($options);

$cache->clean();

?>
Cache Cleaned.
</body>
</html>

cron jobs:

Code:

40 3 * * * wget -o /dev/null -O - http://www.mydomain.com/admin/clearcache.php >/dev/null 2>&1
41 3 * * * wget -r -nd --delete-after http://www.mydomain.com >/dev/null 2>&1

This will clear the cache at 3:40 AM, then spider the site at 3:41 to cause the cache to be rebuilt.

results:

My pages that took 50-60 seconds to display now come up in 0.175 seconds. 9718 DB queries, down to 65.

Before:

Code:

Parse Time: 53 - Number of Queries: 9718 - Query Time: 3

After:

Code:

Parse Time: 0.175 - Number of Queries: 65 - Query Time: 0.01790659312439

Quite an improvement!

Again, this solution appears to work for me (so far). You may get different mileage depending on your store set up.

Zen developers, feel free to throw stones at me if I'm way off base.

My Installation:
Server OS: Linux 2.6.9 (Fedora Core 5)
Database: MySQL 4.1.20
PHP Version: 5.1.6 (Zend: 2.1.0)
HTTP Server: Apache/2.2.2 (Fedora)
Zen Cart 1.3.0.2 (yes, I'm behind...)
Database Patch Level: 1.3.0.2

**DrByte** · 23 Jan 2007, 10:13 AM

That's one way to gain some benefit.

Another way is simply to allocate more RAM to your MySQL processes and beef up its cache settings so that it automatically caches queries and manages what is most current etc.

**j0ney3** · 26 Jan 2007, 08:38 PM

Hello,

I've just tried this and it's dropped my page parse times substantially. I would recommend it to anyone who is suffering from a lack of resources.

Parse Time: 2.752 - Number of Queries: 417 - Query Time: 0.1318254763031
vs.
Parse Time: 0.278 - Number of Queries: 271 - Query Time: 0.082182839813233

Parse Time: 0.858 - Number of Queries: 329 - Query Time: 0.11570456744385
vs.
Parse Time: 0.265 - Number of Queries: 262 - Query Time: 0.072043928604126

I'm going to be applying this caching scheme to other areas of my cart, perhaps the category menu?

Thanks!

**Armen52** · 21 Feb 2007, 07:09 PM

I am desperately trying to use this as a solution to speed up my installation of ZenCart on Dreamhost, at the very least as a temporary workaround until I move the store to an approved and faster host.

I have finally gotten PEAR installed and the code above does not throw errors when trying to load the site; that is, until this morning it was not locating the Cache_Lite files to load up.

Now that the files can be found (had to modify the include_path), nothing seems to be any faster on the site. How can I know that the PEAR cache is being used and functioning properly? Is there any kind of test I can run or snippet of code that will produce some output to verify?

Any help is appreciated.

Thanks,
Armen

**Armen52** · 22 Feb 2007, 06:13 AM

As an update, I believe I have solved my problem and the caching is working for me now.

A note to folks who are doing this on a shared hosting account and following the original poster's instructions:

1) Make sure you use fully qualified path names wherever you need to provide a path, including in the PHP source code sample above.

2) Make sure that you have write permissions on the directory you're asking the Cache_Lite to cache into. In the sample code above the poster used /tmp/ which I didn't notice until tonight; as a shared hosting user I do not have write access to that folder on the server. Just change that path into a fully qualified one to some folder you create in your user folder. Something like ~/pear_tmp/ *without* the tilde.