Enabling Redis setting in the config.local.php file
// Cache backend
// Available backends: file, sqlite, database, redis, xcache, apc, apcu
// To use sqlite cache the "sqlite3" PHP module should be installed
// To use xcache cache the "xcache" PHP module should be installed
// To use apc cache the "apc" PHP module should be installed
// To use apcu cache the PHP version should be >= 7.x and the "apcu" PHP module should be installed
$config['cache_backend'] = 'file';
$config['cache_redis_server'] = 'localhost';
$config['cache_redis_global_ttl'] = 0; // set this if your cache size reaches Redis server memory size
Enabling Redis setting in the config.local.php file
// Cache backend
// Available backends: file, sqlite, database, redis, xcache, apc, apcu
// To use sqlite cache the "sqlite3" PHP module should be installed
// To use xcache cache the "xcache" PHP module should be installed
// To use apc cache the "apc" PHP module should be installed
// To use apcu cache the PHP version should be >= 7.x and the "apcu" PHP module should be installed
$config['cache_backend'] = 'file';
$config['cache_redis_server'] = 'localhost';
$config['cache_redis_global_ttl'] = 0; // set this if your cache size reaches Redis server memory size
If I change 'file' at line 118 to 'redis' my store closes.
Not sure why but on my server when I lookup if Redis is enabled I see this
# for phpver in $(ls -1 /opt/cpanel/ |grep php | sed 's/ea-php//g') ; do echo "PHP $phpver" ; /opt/cpanel/ea-php$phpver/root/usr/bin/php -i |grep "Redis Support" done
PHP 55
Redis Support => enabled
PHP 56
Redis Support => enabled
PHP 70
Redis Support => enabled
PHP 71
Redis Support => enabled
So why does CS Cart V4.6.3 not work with redis as backend cache ?
It works for me just fine, maybe try using the store_prefix feature. This is located in the config.local.php.
This makes sure when you have multiple CS-Cart installations and just one redis engine that the sessions do not merge with eachother / override eachother.
Also, you could try flushing the redis cache, as it could be possible that it reached its storage limit.
It works for me just fine, maybe try using the store_prefix feature. This is located in the config.local.php.
This makes sure when you have multiple CS-Cart installations and just one redis engine that the sessions do not merge with eachother / override eachother.
Also, you could try flushing the redis cache, as it could be possible that it reached its storage limit.
What should this store_prefix be ?? what goes in between the quotation marks ?
I'd love to know if you think redis is faster? My host suggested it as well but I read cs-cart currently recommends file.
Yes Redis is way faster, this is because of the fact that it stores everything in the RAM. Also using Redis for the sessions instead of the database should give a significant boost as it allows for quicker access and is less intensive on the server itself.
No disrespect but I never saw any difference between sqlite, database, redis, xcache, apc etc. I used all of them and monitored via paid Pingdom account for changes. The delay with CS-Cart is caused by CS-Cart's own logic of querying Database for many times for the same information. They never retain the data and try to reuse it. Session storage is dismal so it makes no significant difference where you see a drop from 900ms TTFB to 300ms TTFB. It is more like 900ms down to 880ms if it is.
Perfect example that I just pulled from my Admin panel debug screen. ?debug=1
CS-Cart runs two redundant queries that causes 1.06 seconds delay. What if these queries were combined into one query? Would save 0.5 seconds. You won't save this much by tweaking any settings in config.local.php.
Test it with yours, you will see the same results. Instead of optimizing their logic and code, they will tell me to dump data in my cscart_logs table. That is the only source of information for what's going on in my store why do I need to dump it? You change logic and write better software........
115 SELECT COUNT(DISTINCT(cscart_logs.log_id)) FROM cscart_logs LEFT JOIN cscart_users USING(user_id) WHERE 1 AND (cscart_logs.timestamp >= 1508940693 AND cscart_logs.timestamp <= 1511622693) 0.54437
116 SELECT cscart_logs.*, cscart_users.firstname, cscart_users.lastname FROM cscart_logs LEFT JOIN cscart_users USING(user_id) WHERE 1 AND (cscart_logs.timestamp >= 1508940693 AND cscart_logs.timestamp <= 1511622693) ORDER BY cscart_logs.timestamp desc, cscart_logs.log_id desc LIMIT 0, 10 0.52371
Well for what is worth I tried pasio as my prefix but still the store when closed upon me. Not sure why actually, I did not stick around to enable the debug mode. Poppedweb (Harm) has pointed me in other ways to reduce our page loading times. It is now between 1.2 and 2.5 sec
Well for what is worth I tried pasio as my prefix but still the store when closed upon me. Not sure why actually, I did not stick around to enable the debug mode. Poppedweb (Harm) has pointed me in other ways to reduce our page loading times. It is now between 1.2 and 2.5 sec
// Set to unique store prefix if you use the same Redis/Xcache/Apc storage
// for serveral cart installations
$config['store_prefix'] = 'pdx';
I have multiple store domains on the server pointing to one database. I'm not quite sure how the store_prefix config setting should be setup. I can see redis listed when i check my phpinfo file so i guess it is setup ok.
What could be causing the connection to be refused?