Smarty Caching - Server Side Cache

[datakick]

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]

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]

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]

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]

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]

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]

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]

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]

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.