Decision system optimization
A little decision system revision has been done. Before, we send the people to the victim that were nearest to the victim based on their radius. We only calculated their route distance to check that the real route distance was smaller than 1000 meters. So if we would send 15 people these people would be the first 15 out of 60 people sorted on their radius distance between them and the victim and with a real route distance smaller than 1000 meter. Also to check the route distance for sending a volunteer to an AED and then to a victim was done by two API calls, one for calculating the route for a volunteer to an AED and one for from an AED to the victim.
Now I have done it a little different, I calculate the real route distance for all 60 people first and sort those first. And then send the first 15 to the victim with a route distance smaller than a 1000m and for the remaining I select the next 15 people in the sorted list who have a route distance smaller than 1000 meter with an AED in the route, the AED is seletected that has the least impact on the route distance for that volunteer. I have calculated that it takes 4 seconds for 60 Google Maps API calls. We need at least 15 Google Maps calls in the former decision system which would take around 1 second, so for the extra 3 seconds we could possible save minutes in real routing time! I haven’t done this for the AEDs tough, I could have calculated all routes to AEDs, and from AEDs to the victim for all remaining volunteers but this would be more costly. For example if the first 15 volunteers were picked and we have 5 AEDs in the vicinity of victim, we would have to make 225 API Calls resulting in additional 15 seconds! And that’s not really necessary because we already send 15 people that are closest to the victim, so they can help the victim while the other volunteers with an AED are on route. Now to be fair in our system if we are lucky we would still have to make 75 API calls resulting in 5 seconds. But the total calculating time is still half of the other calculation. Now as it was done before this would be incorrect because an AED route took 2 API calls instead of one. So this difference would be even bigger. However I did a small optimization, because the AEDs are the same for each volunteer, the same route from an AED to the victim is taken, the only thing that is different is the route to an AED. So if we would have 15 volunteers and 5 AEDs in the old version we would do actually 150 API calls! I have optimized this by calculating for those 5 AEDs the real route distance to the victim. This means we only do 80 API calls instead of the 150 API calls, saving us roughly 5 seconds in calculation time!
Another change is how the messages are pushed to the devices. First I made two lists of notifications, one list of all the volunteers that will receive a notification sending them directly to the victim the other list will contain the volunteers that are send first to an AED. Because of the queue system for the push server, I will now add them to the queue for processing as soon as the volunteer is picked out for notification.
In conclusion, we have added a 3 second calculation for the ordered list on real route distance, but by optimizing saved more than that!