Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1
  • 2

TOPIC: Server question for Limesurvey

Server question for Limesurvey 6 months 2 weeks ago #108299

  • holch
  • holch's Avatar
  • NOW ONLINE
  • LimeSurvey Team
  • Posts: 2950
  • Thank you received: 377
  • Karma: 124
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 | Question Attributes | Workarounds

If you found this answer helpful and it saved you some time please consider a donation to the project to keep Limesurvey going!
The administrator has disabled public write access.

Server question for Limesurvey 6 months 5 days ago #108673

  • rauno_s
  • rauno_s's Avatar
  • OFFLINE
  • Fresh Lemon
  • Posts: 16
  • 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 6 months 5 days ago #108686

  • Gordon55M
  • Gordon55M's Avatar
  • OFFLINE
  • Fresh Lemon
  • Posts: 17
  • 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.

Analysis:
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.

Charts:
2CPU - 4GB RAM
LoadTest2CPU.png


4CPU - 8GB RAM
LoadTest4CPU.png


8CPU - 16GB RAM
LoadTest8CPU.png
The administrator has disabled public write access.
The following user(s) said Thank You: mhkuu
  • Page:
  • 1
  • 2
Moderators: ITEd
Time to create page: 0.135 seconds
Donation Image