• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Zend Redis Cache 1.5.4

No permission to download

Alfa1

Well-known member
Is it still needed to add this to the config:

$config['cache']['enabled'] = true;
$config['cache']['frontend'] = 'Core';
$config['cache']['frontendOptions']['cache_id_prefix'] = 'xf_';
 

Divvens

Well-known member
Just FYI, these errors started popping up after we enabled image proxy (thats the only major change that comes to mind).
@Xon

These errors stopped after disabling image proxy. With image proxy enabled this errors kept occurring. This is on the latest version of the add-on, not sure if anyone else is facing it but the errors I posted occur only when image proxy is turned on. And I've also verified this that the first 2/3 errors are related to an image proxy request which leads to errors on other pages/random pages for that same moment. (12 errors in a single second, but the cause of it at first was something loading from image proxy).

Not sure if its related to the add-on, but I've turned off image proxy for now because I can't have random 'something went wrong' pages showing up to my users. I get mixed content warnings but I think its ok to live with that for a while, I am not technical so I can't really help with more information, but if you need anything specific let me know.

PS. I didn't comment out the save or appendonly options. The config has been the same since installation of the add-on and redis.

Redis information;
 

Divvens

Well-known member
@Xon
Just following up, we had no errors after disabling image proxy for more than 28 hours, but just got one single error now. Maybe it'll help.

This is different from before however, before there'd be multiple errors that would pop up at the same instant (anything between 6 to 15), now its just one. But I thought to keep you informed.

PHP:
Error Info
CredisException: read error on connection - library/Redis/lib/Credis/Client.php:1104
Generated By: Unknown Account, Today at 10:45 AM

Stack Trace
#0 /home/xxxx/public_html/library/SV/RedisCache/RedisDataRegistry.php(198): Credis_Client->__call('exec', Array)
#1 /home/xxxx/public_html/library/XenForo/Dependencies/Abstract.php(147): XenForo_Model_DataRegistry->getMulti(Array)
#2 /home/xxxx/public_html/library/XenForo/FrontController.php(127): XenForo_Dependencies_Abstract->preLoadData()
#3 /home/xxxx/public_html/index.php(13): XenForo_FrontController->run()
#4 {main}

Request State
array(3) {
  ["url"] => string(57) "https://orojackson.com/profile-posts/comments/966380/like"
  ["_GET"] => array(0) {
  }
  ["_POST"] => array(4) {
    ["_xfRequestUri"] => string(36) "/members/friendlydemon.15708/?page=4"
    ["_xfNoRedirect"] => string(1) "1"
    ["_xfToken"] => string(8) "********"
    ["_xfResponseType"] => string(4) "json"
  }
}
 

Divvens

Well-known member
Hmm, maybe I found the culprit of the problem. I've disabled Live Update add-on and gonna wait and see if the errors stop, that was one of the add-ons always showing up in the error logs whenever Redis threw an error. I'll report back if I don't spot any error in 24/48 hours @Xon
 

Xon

Well-known member
Hmm, maybe I found the culprit of the problem. I've disabled Live Update add-on and gonna wait and see if the errors stop, that was one of the add-ons always showing up in the error logs whenever Redis threw an error. I'll report back if I don't spot any error in 24/48 hours @Xon
This is basically a load issue. Please try disabling persistence, or increasing the listening backlog (check the redis.log file /var/log/redis/redis.log to see if you need to adjust net.core.somaxconn)
 

Xon

Well-known member
Xon updated Zend Redis Cache with a new update entry:

Increased minimum supported Redis version to v3.0.0, and updated FAQ & sample config

Updated configuration samples, and tightened up the FAQ. Next release will have the samples and README in the release also updated.

The minimum supported Redis version is now v3.0.0, but it will continue to work with older features. It just means the 'use_lua' option can now be recommended by default.

Please note; the minimum example has changed:
Code:
$config['cache']['backendOptions'] = array(
        'server' => '127.0.0.1',
        'port' => 6379,
        'connect_retries' => 2,
        'use_lua' => true,
        'compress_data' => 2,
        'read_timeout' => 1,
        'timeout' => 1,
    );
The extra timeout options and retry options add a measure of self-healing.
Read the rest of this update entry...
 
Last edited:

Sunka

Well-known member
@Xon, regarding updated minimal configuration...
I have this in config.php
Code:
$config['cache']['enabled'] = true;
$config['cache']['cacheSessions'] = true;
$config['cache']['frontend'] = 'Core';
$config['cache']['frontendOptions'] = array(
'caching' => true,
'cache_id_prefix' => 'xfredis_',
'automatic_serialization' => false,
'lifetime' => 0
);

$config['cache']['backend'] = 'Redis';
$config['cache']['backendOptions'] = array(
'server' => '127.0.0.1',
'port' => 6379,
'connect_retries' => 2,
'use_lua' => true,
);
require(XenForo_Application::getInstance()->getConfigDir().'/SV/RedisCache/Installer.php');
What is missing there (from your suggestion in FAQ) is this:
Code:
$config['cache']['frontendOptions']['cache_id_prefix'] = 'xf_';
and this inside $config['cache']['backendOptions'] = array(
Code:
 'compress_data' => 2,
       'read_timeout' => 1,
       'timeout' => 30,

Could I just add this missing parts,and that is Ok, or should I remove some of old rows (some conflict maybe?)?

In the end it will look like this. Is it OK?

Code:
$config['cache']['enabled'] = true;
$config['cache']['cacheSessions'] = true;
$config['cache']['frontend'] = 'Core';
$config['cache']['frontendOptions']['cache_id_prefix'] = 'xf_';
$config['cache']['frontendOptions'] = array(
'caching' => true,
'cache_id_prefix' => 'xfredis_',
'automatic_serialization' => false,
'lifetime' => 0
);

$config['cache']['backend'] = 'Redis';
$config['cache']['backendOptions'] = array(
'server' => '127.0.0.1',
'port' => 6379,
'connect_retries' => 2,
'use_lua' => true,
'compress_data' => 2,
'read_timeout' => 1,
'timeout' => 30,
);
require(XenForo_Application::getInstance()->getConfigDir().'/SV/RedisCache/Installer.php');
 

maxicep

Active member
Yeah you have changed the connect_retries 1 to 2, compress data 1 to 2, read timeout empty to 1 and timeout 2.5 to 30 for me . I changed and i will look that.
 

Xon

Well-known member
Please be aware I'll be adjusting the 'timeout' recommendation after I do some more testing.

"redis-server --version"
The add-on also reports the redis version it is talking to in the admincp home page.

@Xon, regarding updated minimal configuration...
I have this in config.php
Code:
$config['cache']['enabled'] = true;
$config['cache']['cacheSessions'] = true;
$config['cache']['frontend'] = 'Core';
$config['cache']['frontendOptions'] = array(
'caching' => true,
'cache_id_prefix' => 'xfredis_',
'automatic_serialization' => false,
'lifetime' => 0
);

$config['cache']['backend'] = 'Redis';
$config['cache']['backendOptions'] = array(
'server' => '127.0.0.1',
'port' => 6379,
'connect_retries' => 2,
'use_lua' => true,
);
require(XenForo_Application::getInstance()->getConfigDir().'/SV/RedisCache/Installer.php');
What is missing there (from your suggestion in FAQ) is this:
Code:
$config['cache']['frontendOptions']['cache_id_prefix'] = 'xf_';
You already have 'cache_id_prefix' set, no need to change it.

These two statements are equivalent:

$config['cache']['frontendOptions']['cache_id_prefix'] = 'xfredis_';
and
$config['cache']['frontendOptions'] = array(
...
'cache_id_prefix' => 'xfredis_',
...
);

and this inside $config['cache']['backendOptions'] = array(
Code:
 'compress_data' => 2,
       'read_timeout' => 1,
       'timeout' => 30,

Could I just add this missing parts,and that is Ok, or should I remove some of old rows (some conflict maybe?)?
It is fine to leave it as it. I do recommend adding the read time out options.

Yeah you have changed the connect_retries 1 to 2, compress data 1 to 2, read timeout empty to 1 and timeout 2.5 to 30 for me . I changed and i will look that.
Yeah. use_lua is functionally the important one, as it causes a different codepaths to be used to execute multiple Redis commands as a single unit on the redis server.

Adding a read timeout means it doesn't stall forever waiting for a reply, and the 'timeout' is how long will be spent trying to connect. I can't remember why I changed it to be such a high value so I'm going to re-test things and likely will recommend reducing it to 1 second (or even 0.5 seconds!!)
 

Sunka

Well-known member
I ended up with this:
Code:
$config['cache']['enabled'] = true;
$config['cache']['cacheSessions'] = true;
$config['cache']['frontend'] = 'Core';
$config['cache']['frontendOptions'] = array(
'caching' => true,
'cache_id_prefix' => 'xfredis_',
'automatic_serialization' => false,
'lifetime' => 0
);

$config['cache']['backend'] = 'Redis';
$config['cache']['backendOptions'] = array(
'server' => '127.0.0.1',
'port' => 6379,
'connect_retries' => 2,
'use_lua' => true,
'compress_data' => 2,
'read_timeout' => 1,
'timeout' => 1,
);
require(XenForo_Application::getInstance()->getConfigDir().'/SV/RedisCache/Installer.php');
I changed timeout to 1 (from 30) and we shall see is it going to be OK.
 

maxicep

Active member
@Xon I don't understand exactly what we can use the slave/master redis servers. I think it needs on very very biggest xenforo forums which running on multi servers, isn't it ? There are options, right. But i have a strong server which running every service on same machine and i can't configure to another server for redis ( also i think it occurs some latency due tcp/ip connection ) So, do i need to create slave redis server on the same server which running the master ? Or just master is okay?
 

Xon

Well-known member
@maxicep Yes, it is designed for multiple servers.

Instead of LCache, which uses APCu for the local copy, I just use a Redis instance in a master/slave setup. APCu has some incredibly nasty behaviour for how it expires/handles being full*. Redis slaves are also dead simple to setup, and it automatically handles resync for you.

The Redis master was generating 40mbit-60mbit of traffic, for what is basically <60mb of cached data. By moving to issuing reads to the local slave this slashed the traffic the Redis master had to send.

About the only reason to setup master/slave on the same box is so you can configure the slave to persist to disk while the master avoids touching the disk, this allows you to avoid the hypervisor cost of forking Redis when it saves to disk.

  • APCu risks deadlocks if a php-fpm child process is killed while in use.
    • Some of my add-ons do use APCu, but only sparingly for machine local configuration.
  • When APCu's performance degrades as the number of cached items increase.
    • It does a linear scan of all cached items inside a mutex.
      • If the TTL/expiry of an item it is looking at has expired, it free's the entry.
    • Vulnerable to massive performance degradation due to memory fragmentation for repeatedly updated content.
  • On being full (or some percentage), APCu throws away everything. It does not implement LRU like memcahe or Redis do.
 
Last edited: