As we move closer to deploying a handful of surveys, I'm wondering if there is any guidance on capacity or any concerns about having 100 people taking a survey at one time. I know this points to the server that's hosting LimeSurvey, but do you have any "best practices" to help mitigate issues?

100 simultaneous survey takes is quite a number. However, I highly doubt this, if you are not sending out an email to thousands of participants at the same time.

There is a sticky post in some of the forums about exactly this topic. Have a look. And using the forum search you will also find quite a few discussions about this.

Limesurvey is (or was?) creating relatively big sessions files, so you need a server with quite some memory to make sure that a lot of concurrent surveys can be filled.

Here a few tips from my side:
Send invitations in batches, distributed over various days, in smaller batches during different times of the day. This is not only valid for Limesurvey but is a good practice for online surveys in general. You never send out the emails to everyone at the same time.

Don't run anything else on your server, just Limesurvey.

Make sure that you have decent memory size available (your server software will already use some of the memory, even without any participants answering, so keep this in mind).

Thank you for your response. Forgive my ignorance, but i did search the forums and did not find any specific guidance.

Please point me to the sticky post "about exactly this topic." I just looked and don't see it.

I'm working with an organization that plans to ask its 30,000 members to take the survey. Of course, we have no idea how they will respond, but I'd like to be as prepared as possible. So far, with a handful of testers, everything seems fine. The environment I currently have is a Virtual Private Server on a host that is primarily running LS.

OK, seems that the sticky post is not there anymore. Someone must have deleted it.

I had collected a few posts about this topic from the forum and then Limesurvey kicked me out, sorry. I don't have time to gather them again now. But if you search in google with something like: or "concurrent surveys", "concurrent users", etc. you should find a few posts.

Some of them refer to older version, so they might not always apply to the newest version.

teracomp wrote: The environment I currently have is a Virtual Private Server on a host that is primarily running LS.

What is meant by "on a host that is primarily running LS"? This VPS is rented by a provider which provides LS along with the VPS? Or your organization provided you the VPS and stated that not many other VPS are running on that host?

The performance of LS depends on many little things. Beside Hardware the webstack and it's configuration is worth a deeper look.

LS session handling is not very good. When a new respondent hits the server a big session file is created. Depending on your setting the session file is created as a file or as databaseentry. That depending on the PHP settings as well. Filebased sessions are written to a directory defined in php. Mostly it is just tmp but you can define a different directory. Quite often tmp is secured in websetups (e.g separate partition with size limit). That can be a bottleneck if LS writes hundreds of sessionsfiles and they will need to stay there for a while (as long as session time and garbage collector is setup in PHP). So you might end up in 0% free tmp space when using Limesurvey with a secured tmp directory. Holch mentioned memory when it comes to sessions which is less a concern with filebased sessions. It can be a issue when using database sessions.

Memory (RAM) is a concern when it comes to the webserver itself. Depending on what webserver (apache, nginx) is used and how php is executed the RAM is a limiting how many concurrent sessions can be served. And when the webserver is capturing the memory to serve the concurrent users you have to reserve enough RAM for the database to cope with all connections as well. That depends on your database.

Since nothing is know about your webstack and the VPS resources available there is nothing specific to recommend.
Only recommendation: Don't use the invitation tool from Limesurvey when having a huge number of invitations.
You have no enough features to control the sending process over time.

Most effective way to prevent lockups in Limesurvey is to use invitations to the survey.
If you have 30.000 to invite, start with a 10 percent batch. After inviting 3,000 people wait 48h to see what response rate you get.
To keep the load on the server low it is best practice to sent invitations email distributed over a time period. That way you prevent that people hits the survey in the same time frames. Most users see your invitation and directly click on the LINK. They just check the first page. So even if you have sent out emails at 9am 10 am etc. most invitations will be opened directly when hitting or at certain times like 12:00 and 17:00 depending on the typical working schedules. Controlling the invitation process tightly can reduce the peak load for you LS installation.

Thanks for additional clarification. The VPS package I'm using is: www.inmotionhosting.com/vps-hosting (specifically: VPS-1000). My plan is to increase resources if needed and if that doesn't work, move from VPS to Dedicated. The prices move up quickly, so I would like to move up only if necessary!

I installed LS on the server. I have not changed any of the server's configuration, simply the default.

We provision all of our managed VPS Hosting plans with CentOS (Linux distribution) as well as LAMP stack to provide you with Linux, Apache, MySQL and PHP/Python/Perl. This foundation is considered by many as the platform of choice for the development of sites and web applications and gives you a powerful base and framework for your projects

My largest project goes online in January. We're currently in the alpha stage, but quickly moving to beta with projected release by Dec 31st.

Thanks again for your advice.

You can also use the limeservice solution. Our servers are extremely strong, and it will work like a charm:
www.limesurvey.org/services#pricingHosted

Very interesting. I'll definitely keep this in mind!

holch wrote: Limesurvey is (or was?) creating relatively big sessions files...

I think it's really a key point... and hope that some LS dev may read this post and give us some info.

For the moment, I suppose that LS 3.0 will require a reduced session file, right?

Ben_V wrote: I think it's really a key point... and hope that some LS dev may read this post and give us some info.

What info?

I don't think that there will be any changes in LS 3.0 regarding this compared to LS 2.5.

The original LS 3.0 was planned as a complete rewrite, but this was dropped. So I expect LS 3.0 to be an evolution rather than a revolution. Just like it happend with 2.0, which was originally also planned as a total rewrite and then stoppend half way and turned out to be an evolution.

Hi everyone, let me add my "2 cents" on the subject.

To teracomp: according to my experience , 100 users at once is not an issue for LS. It's quite an avarage common load (despite it runs the same time asterisk + cms + jabber+ e-mail server + ftp-server) on one of my VPS servers with 4 Gb Ram / 4 cpu*2.8 Ghz / 40 Gb SSD
As jelo has written before, it's all about your server configuration and a lot of small but important issues.

Not that long ago I've deployed and run such a survey , here're the numbers:

• peak concurrent users simultaneously : ~6 500
• peak load duration: ~75 mins
• mean completed survey : ~15 mins
• TOP display values: peak processors load ~ 68% , peak memory load ~98% (well-known apache behaviour)
• total 40 000+ responces in ~20 hours (miserable night time load not counted)
• invitations sent: 300 000 + (in 1 batch, from other server, not LS, was not possible to split on several batches)

Server used : Cloud VPS scalable (with adjustible configuration) peak load config : 32 Gb Ram / 16 cpu*2.8 Ghz / 10 Gb SSD drive , scaled down to 4 Gb Ram / 2 cpu*2.8 Ghz closer to the end of survey.
* btw - 'sessions' issue wasn't noticed (maybe 'cause tmp dir was unlocked and DB optimized)

Deployment approach applied: each sent kb, each connection second, each server request matters !

My brief step-by-step workaround:


To teracomp: IMHO, mentioned VPS-1000HA-S hosting is not an optimal choice:
- configuration is fixed, you can't scale on-the-fly and increase RAM or Processors q-ty in case of an overload -> go for scaleable cloud server, it's even cheaper in total count (if billed for resources consumed).
- limited bandwidth of 2 TB might be not enough, especially if you'll provide source files from the same server -> look for unlim.
- ensure server connection is at least 100 Mb/s (quite often it's just 10Mb/s)
- if you expect 2000+ users connecting at once - inform your provider, as sudden increase from 0 to 2000+ connections might be evaluated as DDOS attack (at least it looks like ) and your server could be blocked, consult for best configuration settings

Hope that long post wasn't too boring and might be helpfull to someone..