Watching for speed bumps on the digital journey

digital journey DXC Blogs

As your enterprise begins its digital journey, you may notice that, while development tools change, many of the design principles remain. The same is true for my area of expertise: performance engineering.

Over the past decades, we have developed measurement, monitoring and alerting tools to ensure good performance on mainframes, minicomputers, client/server, Web and Web services. Now we need to expand our toolset to the digital world, while keeping the same design principles.

In the past, we monitored workload arrival rate to ensure sufficient server and database capacity. But when we switch to mobile apps – especially ones built around Big Data – there’s a new wrinkle.

Performance engineers are always looking for ways to identify latent demand, that is, requests that users want to have processed that never reach the server. With Web apps, latent demand leads to an unpleasant user experience, but it doesn’t lead to pent up demand. However, with mobile Big Data apps, latent demand can lead to pent up demand that may eventually crush the server.

We recently experienced this when developing a mobile app that monitors driving behavior.

Many insurance companies are using beacons and mobile phones to record driving habits. This trip data is uploaded to servers, and the company analyzes it to reward safe drivers with reduced auto premiums. Unlike with a Web app, if a mobile phone is unable to send a request (i.e. upload data about one trip), the request is not discarded. Instead it is stored on the phone to be retried later. Then the phone has two trips to upload on the next use. Thus, latent demand leads to growing pent up demand.

In our case, server logs were recording trip data only for requests that got through our network layer. Our server monitoring tools showed we were easily keeping up with the workload. But this was incorrect as we later found out there was latent and pent up demand.

Our client planned an expansion of the app, so we built a larger environment to handle more requests and process more Big Data. When we cut over, we were surprised when the number of trips uploaded tripled overnight – and so did the number of errors.

We discovered that while we had conducted adequate pre-GoLive performance testing, we had not anticipated the pent up demand and its impact on the network. Our Internet pipe was quickly saturated by phones trying to upload trip data that had been backed up on their devices. We quickly stabilized the situation by adjusting the burst capacity of our Internet pipe, changing the maximum connections through our firewall, and ensuring enough app threads and Big Data agents to support a smooth flow of trip data.

Our solution used a variation of the age-old “restaurant queuing” problem. To explain the analogy, consider phones as the people who want to eat at our restaurant. The Internet pipe is the highway that people use to get to our restaurant. The firewall is the number of doors into the restaurant. The application threads are the tables in the restaurant. The Big Data agents are the cooks.

In this example, you can easily see the issues that can arise. If there are more people who want to visit the restaurant than the highway can handle, we have latent demand our restaurant never knows about. If we have more doors into our restaurant than tables to support, we have people standing around waiting for a table. These are problems that restaurants – and performance engineers – have dealt with for years.

From the restaurant analogy, we borrowed a solution design for our mobile application. We took the concept of reservations and extended it to include times users wanted to “dine at the restaurant” but were unable to. Not only did we keep track of the number of failed visits but also the reason for the failure: crowded highway, too few doors, no table or not enough cooks.

The phones captured this experience data and relayed it back to us, informing us of the digital experience from their perspective. This information was recorded centrally, analyzed and used to make sizing adjustments.

As technology changes, we will obviously adopt new tools. But we must keep in mind that many of our old design principles still apply. New tools paired with smart, established principles can ensure a smooth ride on the digital journey.


Ken Gottry is a performance engineer whose wide-ranging technical expertise ensures that systems perform, are secure, fail over and are easy to operate and troubleshoot. If a DXC client has technical questions about anything other than application coding and data models, they go to Ken.

RELATED LINKS

Make your mobile apps a gift for customers and employees

Too many enterprises still not doing mobile apps right

5G will transform enterprise mobile

Trackbacks

  1. […] Watching for speed bumps on the digital journey […]

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: