BaseRide server learns time-management How To Make The All-in-One Platform For Connected Vehicles and People On The Move. Vol. 3.

Aug. 24, 2015

We decided to regularly and step-by-step describe how BaseRide platform works. We want to share some technical details that will let you get the process in general and see the architecture. This part is about how our server learned time-management.

“We used 110% of Django and wanted a little bit more”, our senior developer once told me.

I will remind you of some facts. BaseRide is a Big Data, multi-user platform with tens of thousands of objects (people and vehicles) online at the moment. They all act and let us know about that. “I have left a zone”, “The photo of garbage collected at the point 4 is uploaded”, “Mr Z is out off the route” and so on. All this information is converted into incoming requests to our server. And the most significant challenge is to hadle them all properly.

Our server has 3 parts.

  1. The web one which is directly interacting with web. And is also performing long-period tasks.

  2. Receiver-block aggregates data from devices (GPS, sensors, CAN-bus, cell phones).

  3. “Servlets” - it is something created by BaseRide developers, and I will tell about it the 4th part of our story. This time we have a talk about Twisted and users requests.

There is built-in-Django system Celery - it makes synchronuous request handling. But Celery used to lose some requests and doesn’t inform if any process is down and woud never finish. You know, we have long-term tasks which are dreadfully important to be completed. We can’t afford being that much risky.

The BaseRide team decided to be asynchronous and chose Twisted - a system for asynchronous programming. How does it work? Exactly the way it is called.

You set a strictly organized consequence of tasks to be done. And Twisted teaches your server to be more than just a performer and makes it learn the art of time-management.

As a result our server turns to be a very hardworking thing and while it is waiting for response from a database, for example. it pleasantly goes in for something else, very useful and important. Not just wait, I mean.

And if you would ask our server to cook a breakfast, it won’t make scrambled egges at first, slice cheese then and only after that make a cup of lungo to be high energy server this day. No, it will act parallel.

That is why BaseRide can afford having thousands of vehicles tracked and analyzed at a moment. For any amount of companies. With any pool of users.

Besides Twisted addresses nodes as well and so get notifications that the node has a problem, and the process is down and it would be kinda great to do something with it.

Twistedly organized is the 2nd part of our server - the receivers’ block. But our developers decided not to stop and put Twisted on the server as a whole. It means they built the internal structure in an alternative way. Synchronuous Django requests and asynchronous users requests are handled by Twisted. And that gives BaseRide platform an opportunity to launch several processes at once and bring into play all resources of the server. It is multi-core, so we know it will like it.

It brings all BaseRide services high capacity.