I’ve just sent into live an update to the API service supporting Tesco Finder application. The focus has been on improving performance and accuracy of the service for the ever-increasing number of Tesco Finder users.
The “nearest branches” feature is now much more accurate. Before the update, the API tended to favour nearest branches by longitude (east-west of your location) over latitude (north-south), resulting in branches further away but in an east-west direction ending up higher up the list than those north-south. The API was behaving like this because changes in longitude are much greater for the same distance on the ground than changes in latitude where UK and Ireland are located on the planet’s surface. I had over-compensated for this effect in my arithmetic. In fact, for longitude the conversion to distance is the same as latitude except the value is multiplied by the cosine of the latitude. Lesson learned!
Obtaining product information is much faster. This works by pooling the search session to a special account on our grocery API so all Tesco Finder users share the same login session – since you don’t have to login as anyone to use Tesco Finder, the API has to login to a special grocery account in order to search for products and provide pricing and offer information. Before now, each search was preceded by a login for that user – nice and safe in the multi-threaded computing environment of the API. Sharing the same login session is a lot trickier because that session has to be locked to each user in turn while the search takes place. Fortunately it’s so quick that the queue of search requests waiting in turn to lock the session does not build up.
Sharing resources in a multi-tasking web environment can be a dangerous game. Each process (usually a computer script preparing a web page to be sent to your browser – we call this a ‘thread’) must lock the resource so it doesn’t get altered by other threads until this thread is done. If one thread keeps the lock for too long, the backed-up threads (usually other people waiting for their web page to arrive) can grow quickly. If the backup is severe and default memory allocation is exhausted, the operating system starts trying to manage memory by swapping it to and from disk, hitting CPU load and disk response times and slowing things down more. Soon the server hits the digital cliff and the infamous HTTP 500/Too Many Users results, or the server just stops responding at all.
That’s why it’s taken some time and lot of testing to ensure that this programming pain is worth the performance improvement for Tesco Finder customers. I’m glad to say it has worked out well – it’s now live as of 1:30pm today.