I have discovered that clearing the cache is still necessary. How often I am not sure yet. I just noticed that when I was making Status changes in the backend, it was taking too long to change with the “Loading” message appearing at the top. As soon as I cleared the cache, I could change the Status quickly.
UPDATE:
Everything still seems to be working fine. I have decide to disable cache and see what happens. Looking at Google Webmaster in the Crawl Status, I can see that time to load a page is either low or high on a daily basis.
I still have had no issues.
I’ll be interested in your report after disabling cache - this seems to substantially increase load times. In fact, I think the disparity in GW may reflect whether or not cache was recently cleared.
I wonder how Noman and nodame are getting along with this? It would be nice if we could get another 4 or 5 people testing this.
Bob
Here is the crawl stat for before and after comparison. Since 1.3.5 did not use cache, I am hoping this graph will get back to being stable like it was previously.
[ATTACH]1711[/ATTACH]
So far so good. I have added many new products and pages the same day I was dealing with Smarty so I think, is too early to judge, but I can’t complain.
[quote name=‘jobosales’]I still have had no issues.
I’ll be interested in your report after disabling cache - this seems to substantially increase load times. In fact, I think the disparity in GW may reflect whether or not cache was recently cleared.
I wonder how Noman and nodame are getting along with this? It would be nice if we could get another 4 or 5 people testing this.
Bob[/QUOTE]
[quote name=‘Tool Outfitters’]I have discovered that clearing the cache is still necessary. How often I am not sure yet. I just noticed that when I was making Status changes in the backend, it was taking too long to change with the “Loading” message appearing at the top. As soon as I cleared the cache, I could change the Status quickly.[/QUOTE]
[quote name=‘jobosales’]
I wonder how Noman and nodame are getting along with this? It would be nice if we could get another 4 or 5 people testing this.
[/QUOTE]
By clearing the cache, I assume it is adding “&cc” after the url?
Correct me if I am wrong. ^^
Anyway, even before updating to Tool’s version of Smarty, I’ve had to clear/refresh the cache at least once a day already. As I realize that after some period of time, doing update or admin area related actions will be very slow, and by clearing the cache, it become instantaneously faster… (same problem as here:[url]http://forum.cs-cart.com/showthread.php?t=16135[/url])
So I cannot say whether Smarty 2.6.26 is the cause of the problem of having to refresh cache to speed up processing time. As for page load time, I’m unsure how you guys generate the google chart stats.
Well, as I imagined, not having cache has gotten my Google crawling stats back down to a steady level as it was in 1.3.5.
Just to be more accurate, this is only disabling the cache of /var/cache and not /var/compiled.
[ATTACH]1758[/ATTACH]
[quote name=‘Tool Outfitters’]Well, as I imagined, not having cache has gotten my Google crawling stats back down to a steady level as it was in 1.3.5.
Just to be more accurate, this is only disabling the cache of /var/cache and not /var/compiled.[/QUOTE]
Strange that caching is slowing things down. It would be good to get the developers input on this - maybe they have implemented something improperly.
Bob
Hi gang,
I’m looking to join the ranks of folks testing this - but just to try to compare apples to apples, are you guys also using smartoptimizer?
Also, what was the impetus for upgrading? What are the performance issues you are trying to address?
I had my first odd timeout today on an ajax call with an excessive number of persistent user traffic - so I’m willing to see if the cache/compile mechanisms of the newer smarty will address the issue.
After a while the issue subsided, but with increased traffic it seems that the response curve of the site varies considerably.
I’m using Smartoptimizer for the last 2 months. No issues so far. I didn’t even switch it off when upgrading CS to the higher one.
[quote name=‘jagorny’]Hi gang,
I’m looking to join the ranks of folks testing this - but just to try to compare apples to apples, are you guys also using smartoptimizer?
Also, what was the impetus for upgrading? What are the performance issues you are trying to address?
I had my first odd timeout today on an ajax call with an excessive number of persistent user traffic - so I’m willing to see if the cache/compile mechanisms of the newer smarty will address the issue.
After a while the issue subsided, but with increased traffic it seems that the response curve of the site varies considerably.[/QUOTE]
I used the Smart Optimizer for a couple of days but I did not see any difference in page loading times. My pages already load in under 2 seconds without it anyway but the reason I removed it is because it was causing such a load on my server that my account was suspended.
The reason for trying the latest stable version of Smarty is because so many have been having problems with errors and/or slow page loading times.
As an alternative to SmartOptimizer or to be use in conjunction with SmartOptimizer.
[url]http://aciddrop.com/2008/01/03/automatically-join-your-javascript-and-css-into-a-single-file/[/url]
Combines all your javascript files into one file and all your css files into on file.
cs-cart actually has it installed partially. Non-working though.
Download the file at:
[url]http://aciddrop.com/aciddrop/aciddrop_output_filters.zip[/url]
Then install the 2 files here:
core/templater_plugins/outputfilter.join_javascript.php
core/templater_plugins/outputfilter.join_css.php
Modify the 2 files by setting:
```php
‘cachedir’=>‘/var/cache’,
```
Modify this file:
/lib/templater/Smarty.class.php
Change:
```php
var $autoload_filters = array();
```
To:
```php
var $autoload_filters = array(‘output’ => array(‘join_javascript’,‘join_css’));
```
Oh, you will need to update .htaccess within the ‘/var’ directory.
Change:
To:
This will allow you to access ‘.css’ files within the ‘/var/cache’ directory.
If the css combine file is giving you problems because of relative path to the images, turn it off by changing:
```php
var $autoload_filters = array(‘output’ => array(‘join_javascript’,‘join_css’));
```
to:
```php
var $autoload_filters = array(‘output’ => array(‘join_javascript’));
```
What problem is this trying to solve? Are there new functions in the new engine?
Not sure I’ve become much of a beliver in this approach to generating pages. What’s the difference if you have 10K template files or 2K pages to accomplish the same thing. All the {include file=xyz.tpl param1=1 param2=2} is simply applying the same business logic to display as using any other function-oriented html generator (and most others do it much simpler). It also doesn’t help that cs-cart doesn’t believe in formatting. I.e. some of these template lines are 6 screens wide!
There shoud be a standardization of the template functionality and an intermediary directory or file where the options to specific templates can be configured for a site. Right now, one has to go into the bowels of a particular template to turn things like “show_old_price” on and off. Not much organization to what’s distributed.
But it is what it is… The caching is nice though and definitely speeds things up significantly. Now if the caching was smarter so that when you install/uninstall an addon that has to do with newsletters, the cached pages for checkout aren’t flushed, that would be great. Checkout takes about 10x longer to load after the cache is flushed. So for a reasonable customer experience, have to go through a checkout process just to get the pages cached for the next customer!
So whats the final verdict on this? Im about to push out my top super secret test site and would like to know if this is considered working well for speeding up page load times. Any new updates from those testing it?
I’m not sure if there is a difference or not. The only thing I can say is that 2.6.26 is working without any errors.
What I also can say is that by disabling cache, my site is downloading much faster or more consistantly by Google as you can see by the updated stat below.
[ATTACH]1777[/ATTACH]
Upgraded my version of smarty no problem, I’ve gone through everything I could think of and so far so good, no errors on my part :).
EDIT: Infact i used to get some people complaining about errors upon checkout (quite often), and since the smarty update I’ve not had anyone complain and my sales have increased 
Whether or not this is because of the smarty update I don’t know but thanks Tool for pushing this to everyones attention
Thanks for the report wartornskull.
I probably should have started another thread pertaining to the non-use of cache but I guess it’s a little late for that. Here is my latest results without using cache.
[ATTACH]1810[/ATTACH]
I have not tried zekes new cache method but at this point, I am not sure I even want to use cache all together.
If anyone else is interested in disabling cache, you can comment out the lines in [COLOR=“Blue”]blue[/COLOR]:
/core/class.registry.php
//
// Store data in the file cache
//
private static function _set_cache($name, $data, $tables, $cache_level = NULL)
{
$fname = $name . '.' . $cache_level . '.php';
if (!is_dir(DIR_CACHE)) {
fn_mkdir(DIR_CACHE);
}
$change_cache = false;
if (self::$_cached_keys[$name]['track'] == true && !empty(self::$_cached_keys[$name . '_real_value']) && self::$_cached_keys[$name . '_real_value'] != $data) {
$change_cache = true;
}
[COLOR="Blue"] if (!empty($data) && (file_exists(DIR_CACHE . $fname) == false || $change_cache == true)) {
fn_file_put_contents(DIR_CACHE . $fname, "");
if (file_exists(DIR_CACHE . 'cache_update_handlers.php')) {
include(DIR_CACHE . 'cache_update_handlers.php');
}
foreach ($tables as $table) {
if (empty($cache_handlers[$table])) {
$cache_handlers[$table] = array();
}
$cache_handlers[$table][$name] = true;
}
fn_file_put_contents(DIR_CACHE . 'cache_update_handlers.php', "");
}[/COLOR]
}
//
// Retirieve data from the file cache
there are two caches.
- The var/compiled directory which is a cache of template files. This is the area that Zeke’s changes address (though I expect this to become a mySQL cache rather than an sqlLite cache). I hope so anyway. I don’t want yet another DB sucking up memory and CPU time.
- The var/cache directory which contains cached data structures (language variables, etc.), DB queries and other static (or dynamically applied) data (config settings, appearance settings, etc.).
If you disable the caching in core/class.registry.php then you’re simply forcing a new DB fetch for each “thing” that is cached evrey time it is referenced (like every page load). Queries are cached from fn.database.php. They are keyed by the content of the query. For some repetitive operations (like language variable resolution) I would doubt that caching is a penalty. I.e. if lang var ‘xyz’ has been fetched and resides in the cache then there’s no need to look for the DB query in the cache and use its results. But if each language query is cached then the size of the cache will soon exceed the efficiency is it trying to provide.
As the cache gets larger and larger (more unique queries) then the cost of looking up the cached query exceeds the cost of running the query straight-up. It does not appear that the cache is hash-based (I.e. using a hash table and linked lists for the duplicate hash keys). Nor does there appear to be any “cache aging” algorighim that will flush old cache entries to keep the cache as concise and relevant as possible. Hence I’m assuming the lookup is for the most part linear.
I think the best practice would be to leave caching on and flush it once a day or so depending on your site activity. I believe this would provide the most optimal results.
My experience is that disabling the template cache (var/compiled) makes checkout and other “template centric” operations very slow (for the first load). Remember that the template has to create a compiled version (php file) for to be used. If it’s not cached then it has to be recreated each time. There is a noticeable difference going from the cart or product detail page to the checkout page (single page checkout) depending on whether the template cache has been flushed or not (either consciously by ?cc or by the system like uninstalling/installing an addon).
I think you also need to account for much more caching going on than may be realized. I.e. the browser’s cache, any proxy server or router caches, etc.
Just my two cents and two cents doesn’t buy anything anymore.
Thanks for the description tbirnseth.
The only thing that I am disabling is the /var/cache and not /var/compiled. The only thing that was used in 1.3.5 was /var/compiled which is what gave me the idea of disabling /var/cache in 2.x to bring the downloading times down and stable. As a result, my downloading times and stablity are even better than 1.3.5 and I don’t have to clear the cache how many ever times a day. I don’t even need to clear /var/compiled unless I make any changes.
Edit: I just had a look at zeke’s file and you have it backwards tbirnseth. It addresses /var/cache, not /var/compiled.