Scaling Tech Within Africa: Spotlight on Junebug
As we begin to expand our maternal health platforms to other countries in Africa, we are trying to explore different technologies and how they can be adapted to various national contexts. We will be launching Family Connect this month in Uganda with our partners UNICEF and the Ugandan Ministry of Health. The platform uses RapidPro, an open-source tool that helps scale projects, and was built in conjunction with Nyaruka and UNICEF. RapidPro is a recent technology that allows service designer and content specialists to visually build interactive messaging applications.
But we know Rapidpro only understands messages in a few specific formats: we often still need a “translator” between Rapidpro and the mobile network operators sending the messages. This is where our messaging gateway, Junebug, comes in and supports us in this translation. Essentially it takes the messages and sends them to the MNOs in a way that they can be then sent to our users.
Our platform with the South African National Department of Health — MomConnect — has reached over 1.3 million moms. This was a good indication of scale and performance desired for FamilyConnect. The goal essentially is to create a benchmarking suite for Junebug that can track our capacity and run at regular intervals. It gives us the numbers that shows us how fast we can process messages at a time. This would help us find any bottleneck, and implement fixes within Junebug if necessary to improve performance.
Junebug as a messaging gateway is the backbone behind our maternal health platforms. For benchmarking, we take one side of Junebug, and run a script that emulates a user. This “user” sends a message, either through a USSD channel (often an HTTP based integration), or an SMS channel (often an SMPP based integration). Regardless if you understand the technical aspects behind HTTP and SMPP, they are essentially two common Junebug channel integration types that we are testing for.
But translation goes two-ways. When the user responds, we have a simple application that receives an HTTP request from Junebug with the user’s message, and sends a reply back through another HTTP request. During these tests, we also record the maximum memory used by Junebug.
The user then waits for a response. After receiving a response, the process starts again with the user sending another message. We can set the amount of users simultaneously trying to use the system. We record the rate of the interactions (a message followed by a response), as well as the latency of each interaction.
A single benchmark is a series of 10000 interactions. We do a benchmark for both the USSD and SMPP channel types. And we want to mimic and predict for the real world as much as possible — users don’t send messages in silo — so we test with groups of 2, 5, 10 and 20 users for each channel type.
Junebug is written in the Python programming language. There are different implementations of the language, and we ran our benchmarks in March 2016 against the latest version of Pypy.
So what did we find out?
Message Rates
For Our Messages Rates we saw that we were able to handle between 131 and 158 interactions per second. We say interaction to note both a message and its response. With these results we know that Junebug will definitely be able to handle the bulk of our capacity requirements. Mobile network operators normally only allow message rates that are less than half of this.
Latency
Less important for the SMSes, but very important for USSD sessions is the latency, which is defined as the amount of time between when the user sends a message to when the user gets a reply.
For the results, we see an overall trend where we have a minimum latency (around 80ms on our test system) that is constant until we hit a high enough messages in a group to max the efficiencies out. From then on the latency increases linearly with the amount of concurrent users. This behaviour was expected.
Memory Usage
We wanted to test the amount of memory Junebug uses on the machine it’s running — but we noticed the memory was actually growing the longer we ran the program! Of course this is strange as we would expect memory to plateau after reaching a peak once it started.
Due to the benchmark tests we ran, we managed to find and fix a memory leak. Looking at profiling results, we could see that the bottlenecks in Junebug were due to another software component, not to any code in Junebug.
After some memory profiling, we discovered a memory leak and patched it. We then ran the same longer benchmarks, with much better looking results.
We can see that the SMS channel uses more memory. We can also see that there are no longer any memory leaks, as the memory usage stayed flat no matter how many messages we sent. Overall, the amount of memory that you will need for Junebug depends greatly on the type of channels you want to run, as well as the amount of channels that you want to run.
Conclusion
We’re really excited to be working with UNICEF on our maternal health applications in Uganda. Junebug complements RapidPro very well by enabling both USSD and SMS integrations. Since version 3.0.34 Junebug is now part of the standard set of channels available in RapidPro. We’re excited to see how these tests pan out as we implement the program, and begin sending messages to women across the country.
Written by Rudi Giesler, Software Engineer at Praekelt.org
