We would like to use a Kolibri RPi 4B+ (4GB RAM) micro-server using the Kolibri RPi image, to support students across multiple classrooms.
We plan to network the RPi to a number of WiFi Access Points, one per classroom, in order to support the required number of simultaneous connections.
The goal is to try to have all the students’ accounts on one (or a few) Kolibri device(s) if possible so that student progress and system usage statistics can be gathered in one place. Also to keep the cost of the system down to a manageable level.
My question is: what is a realistic number of students that can be supported from an RPi 4 Kolibri server, assuming there are no technical issues of connectivity?
The first item is whether there is any hard limit on the number of student accounts that can be set up on the device? (e.g. is setting up 200 - 300 accounts possible)
The second item relates to the workload on the Kolibri device from having a fairly large number of students using the content from the Kolibri device at the same time (possibly 100 students at a point in time). Obviously this is not a simple thing to test for without setting up a real world scenario.
I realise there will be no hard and fast answer to this question, and there will be many variables around what constitutes typical student usage patterns.
What I am hoping to get is some real world experience from people who have done something similar previously, even if it was not with RPi 4 specifically.
Thanks in advance for any feedback.
Hi @tgillett, thank you for posting and apologies for late reply.
We have not tested the exact system configuration you describe, but in some of the previous tests we arrived to the recommendation of up to 25 concurrent users accessing the server. Important thing to remember is that this limit refers only to users making the simultaneous requests to the server, not the number of accounts created on the server’s facility. For example, you could have several hundreds of learner accounts created for your facility, but the server cannot support them connecting all at the same time. Number of concurrent users will also be affected by the type of resource being requested from the server, so 20 users doing exercises simultaneously will use less server resources compared to 20 users all requesting videos from the server.
We can recommend the following steps for optimization:
- Use an Ethernet cable to connect the RPi to the router or access point
- Use a SSD disk to boot and store the data
- Use the
kolibri-server package (included in the Kolibri RPi image) to make the best use of the 4 cores plus several other optimizations (redis cache, etc.)
If you are considering many more concurrent users, there is a possibility to move from sqlite to a PostgreSQL, but that’s not a default Kolibri setup and would require more sysadmin knowledge to cofigure.
Hi @RadinaMatic
Thanks for your reply and the useful suggestions. Our testing has been going quite well.
For a number of years we have been using low cost wifi router hardware running an OpenWrt firmware build to provide simple classroom based digital library devices to share static content from SD / USB memory devices. Typical devices are GLiNet AR300M, AR750M and MT300NV2. These devices cost around $25-40 each and will support 30+ students accessing the library material concurrently. They are simple and robust and have proved reliable in use. By using a low power wifi router within each classroom, every student gets a reliable, high speed connection without creating wifi and network congestion.
We are now using the same devices as front ends for the Kolibri RPi devices we are testing. As expected, they work well in that role as well.
In addition, we have now added a cache facility into the classroom wifi device to store content from the upstream Kolibri device.
What this means is that when one student in a classroom requests a particular piece of content from Kolibri, it will be stored on the classroom device, so that when more students request the same content, it will be served directly from the classroom device with no significant interaction with the upstream Kolibri device.
As you will appreciate, this dramatically reduces the workload on the Kolibri device and the connecting network. Our testing is showing that we can connect large numbers of students in typical classroom scenarios without creating a significant load on the Kolibri device. This will allow us to reduce the cost and administrative overhead of operating many Kolibri devices across each school.
We have also found that it is essential for the content files to be optimised for web use. We have found that video files in some channels are not correctly optimised and this can affect the performance of the system since the whole file has to be transferred before the video can start playing. There is a separate post on this subject here:
Optimisation of mp4 videos
Anyway, we are continuing to develop this approach and we plan to deploy it to a number of field sites over the coming months.