Smarty Caching - Server Side Cache

datakick · January 10, 2023

Hi everyone,

We have just pushed new functionality into bleeding edge, and I would like to ask for testing if possible.

We have added another option for smarty caching engine -- beside 'File System' and 'MySQL', you can now choose to store smarty cache inside Server Side Cache:

When enabled, thirty bees will use cache implementation selected in Server Side Cache section:

The most interesting options are Redis and Memcache -- these are extremely fast in-memory key-value stores.

Please test and let me know if you find any problems.

the.rampage.rado · January 10, 2023

Just installed on 2 of my shops - it's crazy fast with APCu....

No errors so far.

I think it's time for the FPC to go forever!

Edited January 10, 2023 by the.rampage.rado

datakick · January 11, 2023

9 hours ago, the.rampage.rado said:

Just installed on 2 of my shops - it's crazy fast with APCu....

No errors so far.

I think it's time for the FPC to go forever!

Awesome.

I'm personally using Redis as a caching engine, and it works like a charm. I opted for Redis because I deploy components on different digital ocean droplets - mysql and redis run on different server than php. For people running everything on single server APCu will probably be a faster and simpler solution. It might be less stable solution when server is under heavy load, but generally it should work fine.

Regarding FPC -- it can be great solution if your store does not contain a lot of dynamic data. If you tweak it correctly, punch the right holes for right hooks, it can be blazing fast. Problem is that nobody can tweak it correctly unless they look into modules code. Smarty cache invalidation, on the other hand, is governed by modules themselves. Module author is responsible for proper cache handling, and they usually do it right. For most folks, using smarty cache should be go-to solution.

e-com · January 11, 2023

I tested cache with Redis Server.
There is a fatal error when profiling is enabled:

*ERROR* Error: Cannot instantiate abstract class Db at line 679 in file classes/db/Db.php
*ERROR* Fatal Error: Uncaught Error: Cannot instantiate abstract class Db in /home/ecom/public_html/tbtest/classes/db/Db.php:679
Stack trace:
#0 /home/ecom/public_html/tbtest/classes/db/Db.php(632): DbCore::createInstance()
#1 /home/ecom/public_html/tbtest/classes/Configuration.php(440): DbCore::getInstance()
#2 /home/ecom/public_html/tbtest/classes/Configuration.php(406): ConfigurationCore::loadConfiguration()
#3 /home/ecom/public_html/tbtest/classes/error/response/ProductionErrorPage.php(50): ConfigurationCore::get()
#4 /home/ecom/public_html/tbtest/classes/error/response/AbstractErrorPage.php(43): Thirtybees\Core\Error\Response\ProductionErrorPageCore->renderError()
#5 /home/ecom/public_html/tbtest/classes/error/ErrorHandler.php(125): Thirtybees\Core\Error\Response\AbstractErrorPageCore->sendResponse()
#6 /home/ecom/public_html/tbtest/classes/error/ErrorHandler.php(115): Thirtybees\Core\Error\ErrorHandlerCore->handleFatalError()
#7 [internal function]: Thirtybees\Core\Error\ErrorHandlerCore->uncaughtExceptionHandler()
#8 {main}
thrown at line 679 in file classes/db/Db.php

datakick · January 11, 2023

1 hour ago, e-com said:

I tested cache with Redis Server.
There is a fatal error when profiling is enabled:

*ERROR* Error: Cannot instantiate abstract class Db at line 679 in file classes/db/Db.php
*ERROR* Fatal Error: Uncaught Error: Cannot instantiate abstract class Db in /home/ecom/public_html/tbtest/classes/db/Db.php:679
Stack trace:
#0 /home/ecom/public_html/tbtest/classes/db/Db.php(632): DbCore::createInstance()
#1 /home/ecom/public_html/tbtest/classes/Configuration.php(440): DbCore::getInstance()
#2 /home/ecom/public_html/tbtest/classes/Configuration.php(406): ConfigurationCore::loadConfiguration()
#3 /home/ecom/public_html/tbtest/classes/error/response/ProductionErrorPage.php(50): ConfigurationCore::get()
#4 /home/ecom/public_html/tbtest/classes/error/response/AbstractErrorPage.php(43): Thirtybees\Core\Error\Response\ProductionErrorPageCore->renderError()
#5 /home/ecom/public_html/tbtest/classes/error/ErrorHandler.php(125): Thirtybees\Core\Error\Response\AbstractErrorPageCore->sendResponse()
#6 /home/ecom/public_html/tbtest/classes/error/ErrorHandler.php(115): Thirtybees\Core\Error\ErrorHandlerCore->handleFatalError()
#7 [internal function]: Thirtybees\Core\Error\ErrorHandlerCore->uncaughtExceptionHandler()
#8 {main}
thrown at line 679 in file classes/db/Db.php

Thanks, fixed in bleeding edge.

the.rampage.rado · January 11, 2023

12 hours ago, datakick said:

Awesome.

I'm personally using Redis as a caching engine, and it works like a charm. I opted for Redis because I deploy components on different digital ocean droplets - mysql and redis run on different server than php. For people running everything on single server APCu will probably be a faster and simpler solution. It might be less stable solution when server is under heavy load, but generally it should work fine.

Regarding FPC -- it can be great solution if your store does not contain a lot of dynamic data. If you tweak it correctly, punch the right holes for right hooks, it can be blazing fast. Problem is that nobody can tweak it correctly unless they look into modules code. Smarty cache invalidation, on the other hand, is governed by modules themselves. Module author is responsible for proper cache handling, and they usually do it right. For most folks, using smarty cache should be go-to solution.

Yes, exactly. APCu is plenty sufficiant for me. I have no need currently to split the servers.

e-com · January 12, 2023

12 hours ago, datakick said:

Thanks, fixed in bleeding edge.

Now it's OK.
That's by the way, PHP 8.2 compatibility can be improved.

Message: Creation of dynamic property AdminCoreUpdaterController::$total_cache_size is deprecated
Location: classes/controller/Controller.php line 173

Message: classes/controller/Controller.php: Method ControllerCore::getController() is deprecated. Called from tools/profiling/Tools.php:109
Location: classes/Tools.php line 1456

Pedalman · February 3, 2023

Great news that we can rely on new techniques to boost loading performance of our shops (on customer's side)!

However, I checked my consoleH (host: Hetzner) and I can or better have the php option ACPu (and OPcache ?!) activated. Redis needs a manual install and I do not know if I have to manage it or configure it after I did install it...

Also I do not understand why we still have the option to use ACP when there is ACPu.

Quote

Note: apcu is not the same as apc! APCu is the official replacement for the outdated APC extension. APC provided both opcode caching (opcache) and object caching. As PHP versions 5.5 and above include their own opcache, APC was no longer compatible, and its opcache functionality became useless. The developers of APC then created APCu, which offers only the object caching (read "in memory data caching") functionality (they removed the outdated opcache).

Moreover, I as a normal merchant never understood why there are two categories in the performance options:

Smarty - Application-Cache
Server-Side Caching
Full-Page Cache (that is said to have never really worked ? and we were told to deactivate it fore sure, as far as I know)

datakick · February 3, 2023

1 hour ago, Pedalman said:

Also I do not understand why we still have the option to use ACP when there is ACPu.

This is actually just bad text (and link) in back office. Thirty bees is using APCu, not ACP. I will tidy this up.

wakabayashi · December 10

I am playing around with APCu Cache in combo with smarty. How do I know, if it's working correctly?

print_r(apcu_cache_info());

// it returns:

Array
(
    [num_slots] => 4099
    [ttl] => 0
    [num_hits] => 0
    [num_misses] => 0
    [num_inserts] => 0
    [num_entries] => 0
    [expunges] => 0
    [start_time] => 1733873009
    [mem_size] => 0
    [memory_type] => mmap
    [cache_list] => Array
        (
        )

    [deleted_list] => Array
        (
        )

    [slot_distribution] => Array
        (
        )

)

This looks somehow wrong to me!?

On 1/11/2023 at 8:27 AM, datakick said:

Smarty cache invalidation, on the other hand, is governed by modules themselves. Module author is responsible for proper cache handling, and they usually do it right.

What does it mean in practice? Just using $smarty->fetch() is correct, right?

Edited December 10 by wakabayashi

datakick · December 11

Yes, that looks strange. On my testing site, the result looks something like this:

Array
(
    [num_slots] => 4099
    [ttl] => 0
    [num_hits] => 159
    [num_misses] => 38
    [num_inserts] => 19
    [num_entries] => 9
    [expunges] => 0
    [start_time] => 1733902049
    [mem_size] => 56488
    [memory_type] => mmap
    [cache_list] => Array
        (
            [0] => Array
                (
                    [info] => smarty~themes/niara/modules/blocksearch/blocksearch-top.tpl~blocksearch-top|1|1|1|1|8
                    [ttl] => 31536000
                    [num_hits] => 21
                    [mtime] => 1733902049
                    [creation_time] => 1733902049
                    [deletion_time] => 0
                    [access_time] => 1733902266
                    [ref_count] => 0
                    [mem_size] => 1792
                )
        )
)

Looks like your server is not using the case. Did you set "Smarty caching type" to "Server side cache"?

Note that all these settings are multistore, so check that as well.

the.rampage.rado · December 11

Despite running my store on APCu for looong time just tested this for the first time and it returned an empty array for me on the first test.

Then I installed APCu Manager module and the array got populated and now appears to work properly - after each new visit it changes values and increases in size.

I uninstalled APCu Manager and the array is still populated and working but should we keep the module installed so the system works properly?

datakick · December 11

4 minutes ago, the.rampage.rado said:

Despite running my store on APCu for looong time just tested this for the first time and it returned an empty array for me on the first test.

Then I installed APCu Manager module and the array got populated and now appears to work properly - after each new visit it changes values and increases in size.

I uninstalled APCu Manager and the array is still populated and working but should we keep the module installed so the system works properly?

I don't have that module installed, and it works

datakick · December 11

Note: immediately after the cache is cleared, I also get empty data. But after I load front office, the apcu_cache_info returns correct information.

wakabayashi · December 11

3 hours ago, datakick said:

Looks like your server is not using the case. Did you set "Smarty caching type" to "Server side cache"?

Sure. I thought it must be my configuration, but I did a simple test:

$query = new \DbQuery();
$query->select('*');
$query->from('product');
$query->limit(500);
$result = \Db::getInstance()->ExecuteS($query);

$cache = Cache::getInstance();

$cache->set('GENZO_TEST', $result, 6000);

This is is now in the cache array. So the caching seems to work.

I don't use multistore anymore. The Configuration Values seem to be correct.

I haven't installed the module @the.rampage.rado has mentioned...

I will make some further tests.

Edited December 11 by wakabayashi

wakabayashi · December 11

@datakick shouldn't the method Tools::enableCache() be called somewhere? I am not sure, if this is done correctly.

echo $this->context->smarty->caching_type.'<br>';
echo (int)$this->context->smarty->caching.'<br>';

// returns
ssc
0

I am pretty sure, that it's broken somehow. It doesn't even have todo with ssc. The file cache was the same. Now I just called myself Tools::enableCache(). And Tada: the array is filled with lots of tpl stuff 😅 👍

Edit: or is my understanding completly wrong and $this->isCached() needs to be called, so that any cache is happening? Cause I see modules calling it, but the core doesn't really.

@the.rampage.rado how does your array looks like? Is there only module stuff inside or also theme stuff?

Edited December 11 by wakabayashi

the.rampage.rado · December 11

It looks something like that:

datakick · December 11

49 minutes ago, wakabayashi said:
@datakick shouldn't the method Tools::enableCache() be called somewhere? I am not sure, if this is done correctly.
echo $this->context->smarty->caching_type.'<br>';
echo (int)$this->context->smarty->caching.'<br>';

// returns
ssc
0
I am pretty sure, that it's broken somehow. It doesn't even have todo with ssc. The file cache was the same. Now I just called myself Tools::enableCache(). And Tada: the array is filled with lots of tpl stuff 😅 👍

Edit: or is my understanding completly wrong and $this->isCached() needs to be called, so that any cache is happening? Cause I see modules calling it, but the core doesn't really.

@the.rampage.rado how does your array looks like? Is there only module stuff inside or also theme stuff?

This is correct behaviour. The cache is being enabled selectively only when the module requests this (by providing $cacheId parameter to isCached / display methods)

If we were to enable caching globally, then it would basically do the full-page cache functionality. That's not what we want, because we don't have an option to invalidate the cache entries when something changes.

Full Page Cache tries to solve this problem

it tries to determine when to invalidate page cache entry depending on page entity id (when cached entity is changed, PageCache::invalidateEntity is called, flushing all related cache entires)
it punches holes for dynamic hooks

These both operations are not perfect, and do not work in 100% of cases. That's why it's not really recommended to use FPC on most sites.

But it is still much better solution then to enable smarty cache globally for all templates. That would be an absolute disaster.

wakabayashi · December 11

Thanks a lot! @the.rampage.rado and @datakick. The topic "cache" is still puzzling me, but the longer I think about, the more sense it makes. Your answers helped me a lot to understand. Raising the following questions to myself, helped as well:

how would the system know, that this content is always the same for each customer?
how would it know, if the the content is the same for logged in, but differs for not logged in?
how would it know that it's always the same content, after some actions by visitor or merchant in BO?

You can ask hundreds such questions and the system just can't know the answer 🥴 So yeah, to make this cache globally would be a disaster. 😅 And now I also understand, why the full page cache was introduced. It makes a lot of sense in theory. But in pratice, it's kind of impossible for a merchant to set it up correctly. In general module devs should handle it. Good to know, that there is still a lot of room for improvements on my side 👍

I just learnt that in smarty we can use something like:

{include 'sub_template.tpl' caching}

Probably useful, if you include always the same content 🫠

Edited December 11 by wakabayashi

wakabayashi · December 12

I really like to work with APCu. But I noticed today, that already 20% of my cache was filled. Then I noted, that the system only uses 32M instead of my defined apc.shm_size=512M. Any idea, what could be the reason? I already tried to restart php and nginx server (that's why the full 32M are now available).

datakick · December 12

Did your server used all those 32M of the cache memory? It's possible that it will allocate another segment only when your are running out of the memory

wakabayashi · December 12

No, I was below 32M. My initial setup was:

apc.shm_segments=1
apc.shm_size=512M

Then I tried also with apc.shm_segments=3. But I am not totally sure, what it means. Does it mean 3x 512M or does it mean I have three "segments" with 512M/3?

If I understand you right, I should just let the cache be filled and see what happens when I reach 32M right? Cause the 32M are the default value.

Edited December 12 by wakabayashi

datakick · December 12

I don't really know, you will have to test and let us know 🙂

I never used APCu in production, only on dev site. I don't like the idea that cache is part of the php process, I prefer standalone caching solution (redis for me)

wakabayashi · December 12

I could solve it. In Plesk there are multiple settings. Some of them are globally on the server and some per domain. I had to adjust it in global settings 🥵

wakabayashi · December 13

I believe it's not possible to fill the APCu cache by a cronjob. This is a big drawback in my use case. I am trying to use redis now. Doesn't seem to be much more complex 😏

Sign In

Smarty Caching - Server Side Cache

Recommended Posts

datakick

the.rampage.rado

datakick

e-com

datakick

the.rampage.rado

e-com

Pedalman

datakick

wakabayashi

datakick

the.rampage.rado

datakick

datakick

wakabayashi

wakabayashi

the.rampage.rado

datakick

wakabayashi

wakabayashi

datakick

wakabayashi

datakick

wakabayashi

wakabayashi

Create an account or sign in to comment

Create an account

Sign in