Check out the LimeSurvey source code on GitHub!
Welcome, Guest
Username: Password:

TOPIC: Server question for Limesurvey

Server question for Limesurvey 2 years 7 months ago #108299

  • holch
  • holch's Avatar
  • Offline
  • LimeSurvey Team
  • Posts: 5446
  • Thank you received: 814
  • Karma: 240
Yes, definitely. Don't send out the emails to all at once, if you have a long list. This kills any survey software. Because chances are high that everyone wants to see what it is about and there you go.

We usually split things up as well, even for smaller surveys.
Have a look at the manual! It is a really valuable source for information. Here some helpful links:
Manual (EN) | Question Types | [url=[/url]

If you found this answer helpful and it saved you some time please consider a [url=[/url] to the...
The administrator has disabled public write access.

Server question for Limesurvey 2 years 6 months ago #108673

  • rauno_s
  • rauno_s's Avatar
  • Offline
  • Junior Lime
  • Posts: 20
  • Thank you received: 6
  • Karma: 2
As said previously - concurrency is what kills. You can bring even a very decent VPS down with high concurrency when at the same time a very modest VPS can host huge surveys with low simultaneous traffic. Throttling invitations is always a good idea.
The administrator has disabled public write access.

Server question for Limesurvey 2 years 6 months ago #108686

  • Gordon55M
  • Gordon55M's Avatar
  • Offline
  • Junior Lime
  • Posts: 30
  • Thank you received: 1
  • Karma: 0
User rauno_s just gave a great suggestion on another thread regarding server testing. I figure I'd post my results of his suggestion to use Load Impact to test here. I've included charts of each test.

Virtual Specs:
  1. 2 CPU - 4 GB
  2. 4 CPU - 8 GB
  3. 8 CPU - 16 GB

All tests were run using the same survey and having the application click through the survey. Each virtual testing server was hosted in New York via Digital Ocean SSD's using LimeSurvey 2.00+ Build 130802 and having MySQL hosted on the same server. VU’s were distributed equally from Ashburn, Chicago, Dallas, Palo Alto, and Portland. Each VU was using a generic “Load Impact Browser” to simulate this over an unlimited speed network.

CPU usage is the issue in this test, not memory. The 2 CPU’s survey handled about 100 Virtual Users (VU) before both CPU’s hit 100% and stayed there for the remainder of the 5 minute test. The 4 CPU survey test handled 125 VU’s before being strangled at 100% CPU usage for all 4 CPU’s. The 8 CPU run was obviously the best whereas the 8 CPU’s hit 100% 6 times and recovered very quickly (1-2 seconds) back to a 50-75% CPU usage range. 100% all CPU usage hit at 157, 175, 195, 215, 237, and 247 VU’s, but again they quickly recovered. User load time was predominantly under the 10 second window and hovered mostly at around 4 seconds for the 8 CPU virtual. The 2 CPU and 4 CPU virtual surveys were consistently above 10 second page load times once the CPU’s maxed out.



The administrator has disabled public write access.
The following user(s) said Thank You: mhkuu
Time to create page: 0.226 seconds
Imprint                   Privacy policy         General Terms & Conditions         Revocation information and revocation form