Hello,

This topic is primarily focused on self-hosted Limesurvey instances.

I read that until some time ago, many posts were published about performance optimization and increasing concurrency. I believe that this was mainly due to the implementation of file-based session information. When participants opened a questionnaire, this temporary information was written to disk.

Looking at the code changes, I have the impression that file-based session information was removed / became optional, and that now session information is saved in the database.

This raises the question, what current recommended practices are regarding performance optimization and improving concurrency. Can we share our thoughts about this very important topic?

Thanks!

So limesurvey either lets php handle session storage or stores the sessions in the database. For me, deploying high availability infrastructure for limesurvey meant that I needed shared session state between application servers. (Alternatively, you could use sticky sessions.) My solution was to have limesurvey use php session storage and then setup php to use redis instead of filesystem for session storage. This is very fast and handles as many application servers as needed.

I'm not sure how high of concurrency you need, but our setup has handled tens of thousands of concurrent survey takers.

Redis seems a good idea !

Else :
- session directory in tmpfs (one front serveur)
- memcache
- …

This sounds very interesting! I understand that configuring such architecture can be quite a hassle to "get it right".

Do you mind sharing how you approached this, also technically?

dwight1976 wrote:

Looking at the code changes, I have the impression that file-based session information was removed / became optional, and that now session information is saved in the database.
 

How did you came to the conclusion that the file- based session was removed from LimeSurvey?
 

there are so many different ways to implement a high availability infrastructure, and lots of good info out there

I'll just give an overview of what I've setup.

3 layers:

1. load balancing
keepalived for load balancer failover
haproxy for distributing load across application servers

2. application
nginx to proxy php-fpm
php-fpm for limesurvey

3. storage
mariadb for limesurvey rdb
redis for php session storage (i used table based sessions at first, but they weren't performant enough at scale)
nfs for shared storage between application servers (assets, uploads, etc)

infrastructure in each layer is deployed across different regions/zones as needed (at least 2, can scale up as needed)

the basic idea is no single point of failure, automatic failover, and the ability to scale horizontally as needed to meet demand

Thanks for sharing these details? Impressive how this enables to scale up to tens of thousands of concurrent interviews.

May I ask how many servers you use for the application and database / redis? What are the specs of these machines?

once you've setup the infrastructure, do some load testing and scale vertically/horizontally as needed for the hardware utilization to be reasonable and your budget allows

Sounds good. Do you have tips to perform load testing correctly, especially since we aim to test tens of thousands of parallel connections