I've been playing around with ways to speed up and potentially scale LS with Redis and I've got a couple of findings that I think are quite interesting.
LimeSurvey's own cache
Assuming you've installed redis to your satisfaction, adding the following to your config.php file. As I understand it and please correct me if I'm wrong, this uses redis as a cache for the admin section of LS. I don't think this impacts people taking surveys.
Code:
'cache'=>array(
'class'=>'CRedisCache',
'hostname' => '1.2.3.4',
'port'=>6379,
'database'=>0,
'password'=>'mylongpassword',
'options'=> STREAM_CLIENT_CONNECT,
),
Using Redis to cache user sessions
So Redis doesn't solve the problem of LS writing out the full survey shown to a respondent before the first page of the survey is displayed as
outlined here
. It does let you save your session files to ram on either the same machine or a different one as you choose.
I added the following to my php config...
Code:
php_admin_value open_basedir /usr/share/php
php_admin_value session.save_handler redis
php_admin_value session.save_path tcp://1.2.3.4:6379?database=0&auth=mylongpass
The
open_basedir
stuff came up during debugging, I'm not if it's essential but this came up on my machine.
The advantage here is that LS sessions are now first written to ram and not an SSD (redis subsequently writes its own db to disk to ensure a degree of session persistence). The session file is then always called via ram and not a drive. You can also use Redis to help load balance LS by having multiple servers running LS and if they all use the same Redis db, you should be able to build in some redundancy.
I've setup HAproxy to do ssl termination and I'm sure you can do the same with nginx.