NEED FOR SPEED……Response Times Demystified

At 140 miles on the information super-highway, world was just whizzing by…. The adrenaline rush that I was experiencing was nothing that I had ever foreseen. This was AMAZING!!!! And just than an inaudible SCREECH and…sudden death!!!!! The application had suddenly died on me….For the mission critical application I was working with, the last thing I needed was a delayed response time…This was a deal-breaker! I could sense the client breathing down my neck and snarling at this abrupt HALT if this ever happened in Production!!!

I suddenly broke into a sweat…..my mind was running overtime to figure out the way to overcome this challenge NOW!!!! While researching on the response time issue, I stumbled upon the concept of local storage and client side caching ….. An inner voice whispered to me: “This is where the answer to my problem lies!” I started exploring the concept in-depth and that’s what I thought I should share with you.

“Why Go LOCAL?”

   Think Real –Time and Local storage is the way to go….make this your thumb rule and the response time issue will be “HISTORY”

While Local Storage sounds fancy and geeky, it really is nothing but storage available on client side which can be used by different browsers and native applications to store large amount of data (up to 5 MB), without affecting browser performance.

Real time applications like traffic updates, share-market updates and medical applications totally survive on the response time and cannot have a delay in response or data acquisition, which is when local storage comes into play. Local storage reduces the response time for these applications as it uses locally cached data.

These applications work on the concept of locality of reference which manage to capture the particular user centric data and store it in local cache. As a result, the response time is much faster. Every user displays a pattern while using any application. By using local storage, you can cache the data that is more frequently accessed by the user.

Local Where?

In my case, my client needed the response time for search results to be as near real-time as can be…. Typically, the users would enter the search string and with the insertion or deletion of each character, the search results would need to change instantly.

How I re-built my Rome?

• The user enters the string to search the provider name in the available text box. The string is then matched with available provider names in the local cache
• There are two types of searches that are performed
  • Exact key match which matches the string or key exactly to the available names in the local cache
  • Possible key match which finds possible matches to the string/key.
•  If there are no matches found in the local storage, a remote call to server is made and results are retrieved from the server. In that case, the local cache is updated with the particular key search where a local match was not found. The local cache will also store this key so that it can be utilised for future searches made by the user.
•  For every record that is stored in local cache, a TTL (Time to Leave) is set. If a record is found in cache, its TTL is reset. TTL ensures that only those records which are searched frequently are stored in the cache and those records with a low search frequency are eliminated when their TTL expires. If the user searches the same key or prefix string to the key again, results are retrieved from the local cache.
• Even after the results are found in the local cache, we always have a remote call to the server for the following purposes:
  • To update the cache entries, if the same record is updated on the server. This is important so as to avoid stale data in local cache because even though we would get faster result searches with local cache, that data won’t be of any use if it is out of sync with the server.
  • To append any new records matching the search criteria.
  • To update the TTL.

“The Secret “(code snippet for Local Storage)

This function would store the number of times the user has clicked the button. Even when the session is closed, the click count is stored in the local storage, so that whenever the user starts the session, the click count is incremented from the last checkpoint, i.e. the count stored in the local storage.

Improve & Prove, so that they APPROVE….

This time tracker displays the response time for key search in the application where local storage was implemented and we could see the response time being reduced substantially.

And in the end….

Local cache may not be a replacement for real server side storage, however, it can be used to speed up pages by caching results from API or by caching complex structures created by JavaScript. It can be used to cache data generated on client side or data that is used recursively by the client, hence resulting in a faster and efficient application for the user. Therefore, even though it is not a replacement for server side storage, it actually enhances it considerably.

References

• http://diveintohtml5.info/storage.html
• http://www.html5rocks.com/en/features/storage

All’s well that ends well…a happy client, a happy manager and a happy and a little more enlightened me…. Life couldn’t have been better…till I came across my next challenge!!!!