The User Experience of Server Response Times

: Image via Wikipedia

You may not realize it, but your IT coworkers are also helping with user experience with each decision made regarding network topology. Until I began working for Sprint, I didn't see the connection between network design and interface design. Well, I didn't see it beyond the obvious general rules of thumb: page load times, load balancing based on traffic, and server-side versus client-side scripting. However, my recent projects have underscored the importance of big picture thinking when it comes to user experience.

A recent rollout of ours involved retail store software. My small part in this project was to ensure new contracts and changes to existing contracts generated properly. What seems like a small part of the user experience is actually as critical as credit credit card approval, inventory accuracy, and proper customer data entry. I will discuss this part in a future article, but the point is each of these many systems all work together to provide the user experience in the retail stores.

For my team, after the initial design and implementation of the contract building system (Adobe LiveCycle), user experience came down to server response times. My end-user is actually retail store employees. Sprint customers' experiences are what I'm trying to improve. So by having an intuitive interface naturally the retail employee can quickly help the customer. However, response times are equally important. I really couldn't tell you how many interlocking systems we have to make a transaction happen, probably several dozen. I can tell you that our milliseconds added to the other milliseconds from the other systems means a transaction can take between fifteen and thirty seconds to process. Our end goal became not about how to generate contracts or where to store them; those were easy design decisions. We spent around eight weeks troubleshooting CPU performance problems and increasing transaction processing speed. In the end we measure our success by response times.

On my particular project, performance tweaking took as much time as the actual design and development. This was a new product and we had no benchmarks to work toward. After deployment, it became apparent that transaction speed was paramount to the success of our project.

I'm now thinking in new ways when it comes to initial development of a system. Traditional flowcharts of network topology use various network layers (see illustration) and protocols to demonstrate the type of connection among all of the servers and clients. I'm now thinking in terms of not only HTTP over TCP/IP over Ethernet, but also response times based on production conditions. Response times are tangible and you can use that when considering building out a solution. Load and performance testing of the server to the maximum number of transactions you expect should also help you determine if your servers are capable of handling what you predict.

Response time factors in packet sizes, LAN speed, distance, number of transactions, load balancing, and any overhead. Once you get a formula worked out for your solution, test constantly. This is the lesson I learned. Server response times directly affect whether a customer will leave happy or frustrated from our retail stores. While it's not the fun interface design, it's just as important.