Ok, i dont know why, but my last change was to reactivate ComfortUpdateChecker plugin and deactivate it again, after that i have a lot of work the next days until the last week, and when i go in back to Limesurvey, seems like is all going good again.

When LS runs slow takes me 20-30 seconds to save a change on the survey options, now take 3-4 seconds, and the rest of the admin interfaces responds almost instantly.

It looks like the problem is solved, but i cant make sure that was the problem, if the problem comes back i let you know.

Thanks to all the people for the help they gave me.

brais24 wrote:

Ok, i dont know why, but my last change was to reactivate ComfortUpdateChecker plugin and deactivate it again, after that i have a lot of work the next days until the last week, and when i go in back to Limesurvey, seems like is all going good again.
 

Seems to be an issue for me,
To be reported at community.limesurvey.org/bug-tracker/

Hello,

We are having exactly the same problem, with version 5.6.26 installed on a quality hosting provider with a dedicated server.

We have observed the problem with large surveys, as in the same installation there are small surveys where the slowness problem in the survey configuration area does not exist.

We are talking about a survey with 650 questions organized in 30 groups. These questions are conditional and only 10% are presented to the user depending on an attribute.

Changing any element of the survey configuration area (administrator name, survey name, notification email, whatever) takes more than 3 minutes each time the "Save" button is clicked.

Splitting the survey into smaller ones is not an option. We make more than 400 copies of that survey every year and each of them has different users and different activation times.

However, there is no problem with the Survey Menu options or with editing the questions. In those cases, the saving times are normal. The response time for the survey users is also normal. There is no performance problem.

Any thoughts? the installation works fine with small surveys, so it is unlikely that the problem is due to software or server installation issues.

thanks in advance.

roblej wrote:

We are having exactly the same problem, with version 5.6.26 installed on a quality hosting provider with a dedicated server.
 

Check what happens when using LimeSurvey 5.6.56.
If only one survey and it's copies are having this issue I would recommend to create another copy and delete parts of the survey and deactive certain functions to see if you can find a change in speed. Or create a dummy survey and replace all the survey text with generic text that would allow you to share a LSS export here on the forum to allow other to try to reproduce the issue.

Deleting parts of the survey would mean having a smaller survey, so the problem would disappear or become smaller.

The problem does not only occur with a survey. It is proportional to the size of the survey: the more questions the survey has, the longer the survey setup area operations take.

I have pointed out the most serious case, with 650 questions (and 2 languages) and three minutes to save a modification in a field. But we have earlier versions with 250 or 300 questions where the time to save is 1 or 2 minutes.

thanks for your answer

Deleting parts of the survey would mean having a smaller survey, so the problem would disappear or become smaller.

If you are 100% sure about this, fine. But I find Jelo's approach valid. There might be issues with certain questions, certain equations, etc.

This might be purely survey size related, but it might actually not.

Well, obviously, i'm not sure about any aspect of this problem.

If both of you agree, I guess i should try.

I will.

thanks for your attention and your answers.

If both of you agree, I guess i should try.

I mean at some point you need to try and start trouble shooting or circleing the issue. As we do not experience these issues at the moment, we can't reproduce.

If you provide your LSS, we could see if it has the same impact on our system. But I will not generate 650 Questions in 2 languages to simultate something. Even if it would work for me without problems, this still doesn't proof anything, if it isn't the same survey as your's.

Well, I think the results are already clear:

First, I have made a copy of the survey-master. Time to copy: 1:43"

Survey copy summary

Surveys:    1
Languages:    2
Questions Groups:    30
Questions 633
Question Attributes:    9532
Options:    95
Subquestions:    2125
Predetermined Answer Options:    0
Evaluations:    0
Quotas:    0
Members Quota:    0
Language quota Config.    0
Temas:    1402

Then I made the changes that we usually have to make: change admin name, change basic notification email, Activate survey and change to restricted access. Then, deactivate the survey again to delete new groups of questions.

Action 1: Deleted 5 groups - 30 questions: Formulas
Action 2: Deleted 2 groups - 6 questions (Welcome and demographics) and Text elements: Description and goodbye Message in Surveys configuration menu
Action 3: Deleted 6 groups - 168 questions:  Multiple numerical input (Type: K)
Action 4: Deleted 5 groups - 150 questions:  Multiple numerical input (Type: K)

                                                A1        A2        A3       A4
change admin name:             2:41"    2:10"    1:25"    53"
change basic not. email:       2:32"    2:05"    1:10"    41"
Activate survey:                      23"       15"        19"    17"
change to restric.access:       15"        13"       11"     12"
Deactivate survey:                 16"        13"       10"      9"

I would say that the pattern is clear. Yoour comments are really welcome.

Thanks a lot for your interest.
 

Yes, while we still can't exclude for sure that it isn't due to some specific equations and conditions, your test looks pretty consistent in terms of impact of deleting elements / questions / groups from the survey.

Temas: 1402

What does this mean? Do you have 1402 survey themes?

a quality hosting provider with a dedicated server

How are you connected to the database and what database is used? MySQL, MSSQL, Postgre, etc? Is the database on the same server or on a different server?

jelo wrote:

Check what happens when using LimeSurvey 5.6.56.
 

What version are you using now? Did you update? What version of PHP is used?
Your tests show a near linear relation between amount of questions/groups and duration of tasks.
That looks like a code issue which might be a bug in the LimeSurvey code base or in PHP.
 

For information, developer currently try to improve speed.

For your issue : maybe you can report community.limesurvey.org/bug-tracker/ ?

And try activating debugsql maybe : there a lot more SQL request in 5X than in 3.X
Server configuration are very ipportant too : for example you need to deactivate network check for virus for windows IIS