 |
Forgot last step in "Steps to reproduce":
|
 |
Fix committed to 2.1 branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=10037 |
|
|
Hey Lolo, I did some testing with 3749 participants and 26 attributes, and yes there was a bottleneck that has been fixed and committed. I want to share the test results so as to bring something to your notice. Initially these participants without any attribute visible in the display participant screen were taking 19.4 seconds to load. After removing the bottleneck it came down to 2.25 seconds Then I enabled all the 26 attributes to be visible in the display participant screen , the load time was 30 seconds and with 6 attributes it was 9.12 seconds and with 1 attribute visible it was 4 seconds. I would suggest that you don't keep the unnecessary attributes visible in the participant screen. Even if the attribute value is empty, that will still have an impact on performance. Keep the attributes visible to only the ones you require :) |
|
|
Aniessh, for a real panel provider, having 20 or more attributes is absolutely normal. So if +1 attribute adds +1sec loading time, there still seems to be some kind of bottleneck I would guess. Maybe you can have another look before more bug report about perfomance issues with >10 attributes show up? |
|
|
Hi Aniessh, If panel contains N participants and M attributes, I suspect that the application is performing N x M requests (HTTP+database). This is never going to scale with large amounts of data, as the performance penalty is exponential. The solution, in my opinion, is to aim for an algorithm of linear complexity (or even better, a constant complexity). The best solution would be to fetch all participants and their respective attributes in one single SQL query (and therefore one single HTTP/json request). In issue 06454 I gave an example of such a SQL query. On my MySQL server I have created a view that contains such a query (it returns all participants and all their attribute values in one single SQL query, so I know it works). I know it's easier said than done, and that it would require quite a bit of changes, but it may be the only way to definitely solve the issue. Hope it helped. |
|
|
Fix committed to master branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=10056 |
|
|
Fix committed to 2.1 branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=10066 |
|
|
Fix committed to master branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=10068 |
|
|
Hey Mazi,Lolo @Mazi : sure :) @lolo : thank you very much for the example of the query you gave, I implemented that query and it's working like a charm. Please note I have done this for users with super admin rights only, will try to do for normal users tomorrow ( feeling sleepy ) ,it's quite different from super admin. Although I have one question for you, if you can answer that then we can probably reduce the computation time further, do you have any idea of how to handle the survey count in that single query, I mean it's a join on the number of counts on survey_links table, if that's possible and if you can give an example of the same, I would be more than happy to implement that and the entire data will then come from a single query which will reduce the turn around time even further. As far as the number of http/json requests is concerned, it's has always been a single request to the server, but because of the execution of large number of queries it was running slow. As for statistics , It was taking around 31.33 with 26 attributes and 3749 participants which is now reduced to 4.08 seconds with the same number of attributes, thanks to your example of the query :) |
 |
The fix contains hard-coded table prefixes, see https://github.com/LimeSurvey/LimeSurvey/commit/3c6ea940e6c2d04fccbc33056ab61dd4e5c6bb70#L1R215 Aniessh, can you please fix this? |
 |
Added some fixes to participant panel, including the prefix issue |
|
|
Hi, Recently updated to build 121115, and the rendering performance is now miles away than what it was before. So, congrats for the speed-ups guys, it's much more usable now ! |
- Anonymous
