Hi,

I wonder if you could help me with this peculiar problem.

We're running LimesSurvey Version 1.90+ Build 9642 on a ubuntu server 10.04 running Apache version 2.2.14. My LimeSurvey global settings are set to defaults.

I have a survey which works really snappy when I choose to "Test this survey". But when I activate it (using token management with closed access mode) the survey becomes really slow, the apache2 process reports 100% cpu usage.

Do you know of any reasons why this is the case?

I don't think it's MySQL, it seems to be apache that gets the load. Maybe it has to do with writing tables into the MySQL database, since as far as I can tell this is the only difference between the activated survey and the preview.

Any help will be appreciated!

UPDATE: I have now tested the same system with a very simple survey and that works just fine. I am now leaning towards thinking that the conditions used in the real survey might be the reason for the slowdown. Is there a way to tune apache/php/mysql to make limesurvey work faster? Or maybe other tips?

I have now moved the survey to a very fast server, and the problem is still not solved - apache goes to 100% cpu - even though it is faster than the first server, this doesn't work at all.

The survey is not that big - the result data makes up about 280 columns in Excel. Some questions have conditions, but nothing fancy or homemade scripts.

Is this normal? Is my survey too big?

Strangly I had the same problem last week. The server couldn't handle all the data that was being processed and my site was cut off for a couple of minutes. After that I received an e-mail from my hosting provider that I probably was running some heavy scripts. In fact, the only thing that is on my hosting is Lime Survey!

The problem also started when I published/activated the survey, not when I tested it as administrator.

Yesterday I've tried to activate a new test survey. This time everything went allright. I actually changed only 1 thing: Now I ask the questions group-by-group, earlier (when the server got cut-off) I asked question-by-question.

Maybe you can try to ask every question on 1 page or group-by-group and let us know if that solves your problem?

Thanks for the tip,

I had mine set on "Group by group" but your suggestion got me testing "question by question" just in case. But to no avail I'm afraid, the survey is much too slow. I'm looking into ways to strip away conditions and large questions now.

It's a mystery for me how conditions can slow the survey down more when you run an activated survey, as opposed to previewing it - I would expect the survey preview to be just as slow, right? This leads me to thinking it has to do with the number of columns in the MySQL database.

See bugs.limesurvey.org/view.php?id=5068

Maybe you can attach your survey to the bug report so we have a nice test case.

So in conclusion we could say (I guess):

Don't make a (long) survey with conditions, or make one but ask all questions on 1 page.


I have another question if I may. My survey has 29 questions departed in groups and questions are asked group-by-group. Well the live version is working and not slow or something. But is it possible that when for example 10 persons will fill in the survey within 1 hour, or more persons at a time make the survey, the system will become slow?

In other words: Would you recommend me to delete all the 'condition' questions to make the survey more stable and reliable? Or does the number of people that make the survey has nothing to do with the problem suggested above?

(I'm not that experienced with PHP/MySQL/CPU so excuse me when the question is stupid)

nicks12 wrote: I think you have problem with some condition.

Remove all condition, and after test each condition one by one.

Or maybe send us the survey for testing and look at tit

Hi guys,

And thanks for all the tips!

I've solved the issue by doing a workaround. Instead of duplicating a lot of similar questions, I simply looped the survey by using the END URL, and then passing on the user ID to the next survey.

This solution solved the server issues and another problem of mine, see this post on this forum:
www.limesurvey.org/en/forum/can-i-do-thi...another-way-to-do-it

This solution reduced the number of columns from about 1000 to 150, and it didn't hurt the usability of the survey at all.

To create several surveys that are linked together makes the server happy and your data becomes much tighter!