SkySales Wait Page Optimization

This is a first in a series of tweaks and optimizations for the Navitaire New Skies web platform called SkySales. Look for an article on SkySales development shortly.

Why Wait?

A wait page on the internet (also referred to as an interstitial page) is usually a mundane step in an e-commerce process that’s only purpose is to convey to the user that the system is processing their request and that they should wait patiently. The SkySales wait page has a singular purpose: to persist until all payments on the reservation receive a definite status back from the payment acquirer.

The out-of-the box wait page up through the current 2.x version of New Skies uses sleep methods to jump into a polling pattern that essentially creates a long running process (shown in the diagram below).

Wake me when we get there

The profiled result of a process like this will show a large amount of time spent in the polling method. An IIS thread on the web server and a worker thread are sitting in a Sleep() state most of this time because the actual call to check payment status is tuned and responds sub-second. The result of this is that a precious IIS thread is blocked and not able to serve other requests on the web server. Microsoft published an article on the dramatic effects of Sleeping a thread on not only the pages which use sleep, but on other pages as well.

Keep it simple, silly

I’ve been implementing and customizing on this platform for over two years and never really thought about the performance of something as simple as the humble Wait page. The SkySales wait page is often the “forgotten” page when a new carrier implements a Navitaire reservation system. I frequently see it in it’s non-customized default state on a number of live implementations for New Skies and Open Skies.

It really wasn’t until I saw that we were spending over 90 seconds in three automated passes through our booking process that made me take a look at alternatives. The result is a much more simplified process:

The code to implement the new wait page is about as simple as the process itself. The previous long running process has been replaced with a simple client-directed polling pattern.

The new custom Wait control calls the Remoting Client on all loads except the first one (the payment system wouldn’t be ready for the initial load). All subsequent page loads are done with a JavaScript refresh based on the system payment settings for the role of the logged in person (anonymous in most cases).

That’s it! This new pattern should keep your IIS threads working hard for you. The code for this is available, but I’d rather not just link to it. Send me a message and I’d be happy to forward the code on.