Smarty Template Cache makes store slow and then inoperable

Very good point Barry!

[QUOTE]I had a similar problem which turned out to be a simple change to the memory limit in config file.[/QUOTE]





Try changing this setting to match your server within the config.local.php file



// Set maximum memory limit

@ini_set(‘memory_limit’, ‘304M’);

The PHP default memory limit is 32M. Initially we set the memory limit as high as 200M when these problems arose. When that didn’t help any we set it at 50M. It has been that way for the past three weeks. We are seeing around 500 shoppers a day so keeping the memory limit as small as possible is desirable.



Struck, how did you arrive at a setting of 304M?

Using FF 3.5.6 your site loads pretty quick. The only part of the site that I noticed was any problem was the product details page. The page comes up quick, but it keeps loading. I can’t tell what is loading, but the browser just keeps saying transfering even though nothing changes.



From my end the site loads plenty fast enough. I had no troubles navigating around and looking through your catalog.



By the way, I’m in California.



Brandon

[quote name=‘brandonvd’]The only part of the site that I noticed was any problem was the product details page. The page comes up quick, but it keeps loading. I can’t tell what is loading, but the browser just keeps saying transfering even though nothing changes.[/QUOTE]



Yes, that is exactly the behavior of the product pages that gives us the trouble. We just can’t track down what it is to fix it.



As you noted, the site seems plenty fast, but that is only because we are clearing the template cache out every 10 miniutes. If we don’t, the delay in loading the a product page would take at least 30 seconds.

I am having the same problem as tjordan. Version 2.0.6 did not have this problem. I upgraded to 2.0.8 months ago, and this problem started. I downgraded back to 2.0.6 and stayed there until last month. I thought they would have worked the bugs out by now. I upgraded from 2.0.6 to 2.0.12 last month and the problem is back. My site is www.landsat.com (195K products)



I have been manually clearing the cache to solve the problem. You can also uninstall/re-install “statistics” addon and it will also solve the problem temporarily. If I forget to do this, I get error messages “PHP Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/vhosts/landsat.com/httpdocs/core/fn.fs.php on line 398”



I will setup a script to clear my cache, but this is a Band-Aid to the real problem.



Please help!

I’m sorry to hear you are having this problem too. Are you running on a Windows server too? What is your daily traffic volume?

To this day we still have not found a solution so we typically manually run the clear cache URL on the site many times a day. The scheduled task has always been problematic b/c what we’ve discovered is part of the cache clearing process runs the php files that are located here “httpdocs\var\cache”. And with those php files are constantly changing, it will enevitably generate an error when the scheduled task runs attemptingt to clear the cache. So, at this point, our band aid really isn’t working too well and yours will probably suffer the same way.

I am running a linux DVS, so do not listen to those bashing your windows box.



I think I figured how to force a new file creation. It has been running for 1/2 a day now without the problem. Edit this file.



/lib/ templater/Smarty.class.php





line 149

var $force_compile = false;



Change to:



var $force_compile = true;



This lowered my product pages from 30 seconds to 5 seconds. Yes, my home page also has to recompile each time, but it is worth a 2 second increase for my product pages and add to cart to load in 5 seconds.

[quote name=‘dspotskey’]I am running a linux DVS, so do not listen to those bashing your windows box.



I think I figured how to force a new file creation. It has been running for 1/2 a day now without the problem. Edit this file.



/lib/ templater/Smarty.class.php





line 149

var $force_compile = false;



Change to:



var $force_compile = true;



This lowered my product pages from 30 seconds to 5 seconds. Yes, my home page also has to recompile each time, but it is worth a 2 second increase for my product pages and add to cart to load in 5 seconds.[/QUOTE]

This puzzles me. With this set, you should be recompiling all your pages which should take longer than reading from cache. I am not disputing your results, it just does not make sense to me.



I also mentioned in another thread that the following setting in /lib/templater/Smarty.class.php seems to set no template caching:

/**
* This enables template caching.
*


    *
  • [B][COLOR="red"]0 = no caching[/COLOR][/B]

  • *
  • 1 = use class cache_lifetime value

  • *
  • 2 = use cache_lifetime in cache file

  • *

* @var integer
*/
var $caching = [B][COLOR="red"]0[/COLOR][/B];




Since I see the cached files, this makes no sense. I wonder if the the inline_compilation setting in config.local.php is forcing recompilation:

// Tweaks
$config['tweaks'] = array (
'js_compression' => false, // enables compession to reduce size of javascript files
'check_templates' => true, // disables templates checking to improve template engine speed
[B][COLOR="Red"]'inline_compilation' => true, // compiles nested templates in one file[/COLOR][/B]




Have you experimented with any of these?



Bob

I did not mess with the ‘inline_compilation’, but did try setting cache = 1. This did not work at all.



This “work around” only should be needed for sites with lots of products. Mine has 195,000 and www.floridagunexchange.com has 26,000 products.





I don’t know why it works. Maybe with lots of categories & products, the cache gets too big to be efficient.



If you are having problems with product pages & “add to cart” loading extremely slow (10+ seconds), try changing your Smarty.class.php and clear your cache afterwards.



Edit this file.



/lib/ templater/Smarty.class.php





line 149

var $force_compile = false;



Change to:



var $force_compile = true;



Clear cache [url]https://www.YourSite.com/admin.php?&cc[/url]


[quote name=‘jobosales’]This puzzles me. With this set, you should be recompiling all your pages which should take longer than reading from cache. I am not disputing your results, it just does not make sense to me.



I also mentioned in another thread that the following setting in /lib/templater/Smarty.class.php seems to set no template caching:

/**
* This enables template caching.
*


    *
  • [B][COLOR="red"]0 = no caching[/COLOR][/B]

  • *
  • 1 = use class cache_lifetime value

  • *
  • 2 = use cache_lifetime in cache file

  • *

* @var integer
*/
var $caching = [B][COLOR="red"]0[/COLOR][/B];




Since I see the cached files, this makes no sense. I wonder if the the inline_compilation setting in config.local.php is forcing recompilation:

// Tweaks
$config['tweaks'] = array (
'js_compression' => false, // enables compession to reduce size of javascript files
'check_templates' => true, // disables templates checking to improve template engine speed
[B][COLOR="Red"]'inline_compilation' => true, // compiles nested templates in one file[/COLOR][/B]




Have you experimented with any of these?



Bob[/QUOTE]

We did try reconfiguring some of the smarty variables.

$compile_check should always stay set as ‘true’ if you’re driving the products from a database.

$force_compile works best for us set to ‘false’ b/c in the long run, the homepage will continue to take longer and longer to load.

$caching is set to 0 (no caching) and from what we can tell, does nothing to stop caching



As a new test, we tried setting the $caching variable to ‘1’ and setting the $cache_lifetime variable to ‘600’. DO NOT try this b/c none of your category or product pages will load.

tjordan-



Thanks for the report.



Bob

We can’t put up with this problem any longer. I think we’ve made the decision to pay the CS guys to research and fix it. We’ll let you know what they say…

It would be interesting to see what you guys that are having problems come up with using the latest smarty: [url]http://forum.cs-cart.com/showthread.php?t=15698[/url]

[quote name=‘tjordan’]We can’t put up with this problem any longer. I think we’ve made the decision to pay the CS guys to research and fix it. We’ll let you know what they say…[/QUOTE]



Were you able to get an answer from the CS-Cart team? We are working on a site with a few thousand items and don’t want to run into the same problems that you had. I looked at your site this morning and it seemed pretty quick to me.

[quote name=‘tjordan’]We can’t put up with this problem any longer. I think we’ve made the decision to pay the CS guys to research and fix it. We’ll let you know what they say…[/QUOTE]



So what did they say?

Speaking of cache.



There’s lot of things that cs-cart doesn’t cache when it should. Like products details and product listing. Maybe it’s because the product listing and product details are different for different users of different user groups? Still, I think it can be cache for each user group.



cs-cart actually has a registry class and as well the fn.database.php having a number of caching features like db_cache_query and db_get_cached_result.

I think I am going to have to let cs cart have a look at my site because I thought ow oulkd give it another go and switch from a html catal back to the dynamic one and it starting to kill me dedicated server.



It could be that my instal has something faulty, id unno because most people here seem to have a fast cs cart

Hmm… could be a Smarty template issue.



79 seconds!



This is from the built-in profiler.




```php - Queries time: 5.0854



After init

  • Memory: 9,684,504
  • Files: 51
  • Queries: 12



    Before TPL
  • Memory: 8,117,744 (17,802,248)
  • Files: 29 (80)
  • Queries: 609 (621)
  • Time: 4.7515 (4.7515)



    After TPL
  • Memory: 8,932,248 (26,734,496)
  • Files: 54 (134)
  • Queries: 66 (687)
  • Time: 79.2039 (83.9554) ```

Can someone uninstall SEO addon and run the test again. Not just disabled, but uninstall.



I know the query times below isn’t much slower, but check out the number of database queries!





With SEO:


```php

  • Queries time: 0.0803



    After init
  • Memory: 959,320
  • Files: 52
  • Queries: 12



    Before TPL
  • Memory: 1,443,096 (2,402,416)
  • Files: 26 (78)
  • Queries: 139 (151)
  • Time: 0.0981 (0.0981)



    After TPL
  • Memory: 490,920 (2,893,336)
  • Files: 60 (138)
  • Queries: 98 (249)
  • Time: 0.1366 (0.2347)

    ```





    With SEO uninstalled:


```php

  • Queries time: 0.0820



    After init
  • Memory: 1,000,968
  • Files: 56
  • Queries: 14



    Before TPL
  • Memory: 1,454,504 (2,455,472)
  • Files: 25 (81)
  • Queries: 139 (153)
  • Time: 0.0671 (0.0671)



    After TPL
  • Memory: 659,080 (3,114,552)
  • Files: 61 (142)
  • Queries: 289 (442)
  • Time: 0.1748 (0.2419)

    ```





    98 queries compared to 289 queries with SEO addon turned on.





    Question is, why isn’t SEO queries cached?



    Not a good idea hitting the SQL database so many times on one page load.

[quote name=‘BarryH’]Steady on mate!



You have been a member of this forum for around 14 months and only posted 21 times, ALL questions I bet too!



Anyway, being rude or impolite is NOT the way to get help.



Most people on here offer help and ask nothing in return, so please try a little tact or you may find people ignore you!



I had a similar problem which turned out to be a simple change to the memory limit in config file.[/QUOTE]



What did you change your memory size too?



Thanks