Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open Ethno reported slowing down. Can it be a matter of intensity of coding? #226

Closed
albertocottica opened this issue Mar 11, 2022 · 5 comments
Labels

Comments

@albertocottica
Copy link
Member

albertocottica commented Mar 11, 2022

This is a question for @damingo and, as a fallback, to @tanius.

POPREBEL ethnographers report a much slower performance of OpenEthno lately (three weeks). Is it possible, they wonder, that this is an artifact of the number of codes proliferating? I would be surprised, if that was the case, because this is just text and computers can do text. Are you aware of any other problem that might have occurred?

From Wojciech:

this request: GET /annotator/codes?discourse_tag=ethno-poprebel takes about 10s to get a response from the server

For me, loading https://edgeryders.eu/annotator/codes?discourse_tag=ethno-poprebel takes about 3 seconds.

Again from Wojciech:

Yes, I used API, I mean in a way.... intercepted the request with Burp. BTW, your apache version is super vulnerable :P
One more thing - it seems to be browser dependent. Mozilla shows round 3000ms, Chrome doesn't go below 9000.

@damingo
Copy link
Member

damingo commented Mar 14, 2022

I don't see how this could have become slower in recent weeks, but I know that loading long lists of codes has always been slow (has not yet been optimized at all).
The given request https://edgeryders.eu/annotator/codes?discourse_tag=ethno-poprebel loads about 1600 codes. The top-level codes are paginated to prevent that too many codes are loaded - which does not work in this case, as the top-level codes have many descendants and all of them must be displayed.
This can definitely be optimized e.g. by fragment caching and improved SQL queries. I would have to check in detail what takes up most of the time. Checked the performance in the Chrome Dev Tools and it turns out the server takes about 9s to respond.
I'll have time to fix this next week.

@albertocottica
Copy link
Member Author

Excellent Daniel, thank you so much.

damingo pushed a commit that referenced this issue Mar 24, 2022
@damingo
Copy link
Member

damingo commented Mar 25, 2022

Done. Now only the top-level of codes are initially loaded from the server. This improves the response time from 9s to < 1s. A codes subtree is only loaded from the server when a code is clicked.
Feel free to reopen if anything is missing.

@damingo damingo closed this as completed Mar 25, 2022
@albertocottica
Copy link
Member Author

Thanks, Daniel. It is indeed very fast now, though the increase in performance is predicated on ethnographers using hierarchies. The POPREBEL team is big on hierarchies, but subsequent projects might adopt a flatter approach.

Anyway, we have the ethnographers meeting later today, I will inform them and get back to you if needed.

@damingo
Copy link
Member

damingo commented Mar 25, 2022

Flatter hierarchies (like thousands of codes at the top-level) is also no problem as then pagination is used. Not more than 100 codes at the top-level are displayed on one page. If there are more they are displayed on several pages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants