Willkommen, Gast
Benutzername: Passwort: Angemeldet bleiben:
  • Seite:
  • 1
  • 2

THEMA: Server question for Limesurvey

Server question for Limesurvey 4 Monate 1 Woche her #108299

  • holch
  • holchs Avatar
  • OFFLINE
  • LimeSurvey Team
  • Beiträge: 2671
  • Dank erhalten: 323
  • Karma: 121
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!
Der Administrator hat öffentliche Schreibrechte deaktiviert.

Server question for Limesurvey 4 Monate 3 Tage her #108673

  • rauno_s
  • rauno_ss Avatar
  • OFFLINE
  • Fresh Lemon
  • Beiträge: 16
  • Dank erhalten: 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.
Der Administrator hat öffentliche Schreibrechte deaktiviert.

Server question for Limesurvey 4 Monate 3 Tage her #108686

  • Gordon55M
  • Gordon55Ms Avatar
  • OFFLINE
  • Fresh Lemon
  • Beiträge: 16
  • Dank erhalten: 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
Der Administrator hat öffentliche Schreibrechte deaktiviert.
Folgende Benutzer bedankten sich: mhkuu
  • Seite:
  • 1
  • 2
Moderatoren: ITEd
Ladezeit der Seite: 0.142 Sekunden
Donation Image