We are running into issues, where users are not able to access the content (sometimes kolibri crashes on client side). The same goes for the admin when they try to make any changes to the coach tab or try to access the reports (reports take too long to load)
Can you please recommend architecture based on our load?
Classes - 80 classes
Avg User per class - 400 - 600
Channels - 20 channels
Each class gets the same channel resources copied.
Current Architecture -
Version: 0.17.0
OS: Linux-5.15.0-1075-aws-x86_64-with-glibc2.29
Python: 3.8.10
Installer: deb kolibri-server - 0.5.0-0ubuntu1
Server: nginx/1.18.0 (Ubuntu)
Database: PostgreSQL
NOTE: I saw this thread already - AWS hosting recommendation but I was not able to implement redis connection or shared drive for autoscaling
Hi @safi_khan - as you have seen from the other post, and my extensive responses to your other thread - some of this may just be a result of many of the API queries for coach reports not being designed to handle this load.
There is also the issue that in spite of using Kolibri server, your 4-core server does not appear to be using its full capacity when under load - this makes me suspect that kolibri-server is not actually serving the requests.
Without understanding exactly where the bottleneck is happening, it is hard to offer possible solutions that are more likely to work.
Places to look:
- Database - you showed some DB logs, and it didn’t appear that there were longer running queries, but if I were you I would take another look at this, as I can imagine some of the queries that Kolibri does, particularly on the coach reports might be taking a long time with classes of this size.
- API endpoints - are there a specific API endpoints in your logs that are taking a long time to respond?
- Page load times - how long are the base pages taking to load?
Kind Regards,
Richard
Hi @richard, can you point me to the location where I can find the API respond timing in the logs
The kolibri request logs don’t show the time for the request by default - we normally look at this for cloud systems via the request logs for the cloud service - do you have anything like this for your AWS service?