Slow Registration?

If you live in the United States and you have tried signing up for Health Care Insurance you have experience first-hand the frustration of slow online registration software. An article detailing the Obamacare website claims that the site can handle up to 17,000 people an hour according to CMS, “with almost no errors”. (source: http://bloom.bg/1b4UcJE) How can any errors be acceptable?! With the millions of dollars that have been spent on the Obamacare website, wouldn’t one think that there would be enough checks and balances built in that would make the possibility of an error practically extinct.

One of the fixes to the Obamacare website includes speeding up web pages so that insurance plans are displayed in seconds instead of minutes. This is important to get right. You’ll notice that Google.com has a very uncluttered and very fast loading start page. Take a look at the “view source” sometime. They have even eliminated any unnecessary spaces within their html code.

 Optimize your registration pages.

Here’s a neat tool to see how fast your registration pages are loading. – (http://tools.pingdom.com/fpt/) This tool is ideal because it breaks down the various steps and reports the time each step takes when a web page launches.  (i.e.  the steps are, DNS lookup > SSL handshake > Connect to Server > Transport posted data/content to the server > Server’s time to process > Server transporting content back to browser)

The following items have a big impact on the speed of your online registration pages:

1. How many simultaneous people there are trying to register.
2. How many questions there are on your registration form and how fast the form has been optimized to load.
3. Whether the registration code is compiled, e.g. *.dll (which is faster) or interpreted, e.g. *.asp/*.php (which is slower).
4. How many web servers the ASP (i.e. Application Service Provider) has in their web server farm.
5. How many database servers the ASP has in their topology.   And more specifically, how many replicated slave db servers there are off of the single master db server.  Replicated db slave servers are great for speeding up database queries since “read-only” requests can be done from a replicated db slave instead of the “master” db server.  The “master” should only be used for commands that write or change data.   All of the database queries need to be optimized so that they retrieve data quickly.
6. Whether the webservers and database servers are physical or virtual.   Physical servers are faster, but require more effort to keep up to date and backed up.  So in my opinion, the ASP is better off to use virtual servers except for the “master” db server.  The “master” should be a physical server as it often becomes the rate determining step.

Improving registration time through RDS.

Web page loading speed is proportional to your “rate determining step”. Every ASP has built their technology differently. So the challenge each ASP has is how to:

• identify the rate determining step in their specific online registration software,
• how to eliminate the “slowness” within that rate determining step and then how to identify the next rate determining step.

To identify the rate determining step, you or the ASP are going to need to perform “load testing”.  You’ll need a good load testing piece of software like, Soasta, for this purpose.   (http://bloom.bg/HuvuJn)

.                                                                                                        
                                                                                                      Fig 1. Soasta Cloud Testing Software

At the ASP I work at, we have realized that no matter what hardware, software or topology you have there will always be a rate determining step hiding on you somewhere. Not even Healthcare.gov’s website has enough money to eliminate this speed inhibiting step. So you better get a handle on where your speed limits are and what your rate is determined by. How many people can register at your site at a given moment? Do you know? Shouldn’t you know? What will happen if too many people come to your site?

Governing your registration software.

Every piece of online registration software needs to have a “governor”. This governor will protect you and your clients from going through the registration process, too fast. At e-RegisterNow.com, we set limits on each client so that if their speed limit is reached, a “red stop light”, see Fig 2, appears and asks people to try again at another time. This “stop light” page protects e-RegisterNow against errors and client frustration which can be caused by page loading delays and messed up transactions. The time you ask people to return can vary depending on the load at the time.  This approach is similar the “fast pass” approach at Disney™ parks.

.                                                                           
                                                                                                             Fig 2.  A Red Stop Light Sign

As I close here, I must confess I learned this speed lesson the hard way.  We were selling tickets for a popular consumer show where registration started with a bang at 12 noon on the button.   Unfortunately, we also had a backup beginning at the same time. The e-RegisterNow online registration service was overwhelmed in less than 5 minutes and for the next half an hour, transactions were broken up and registrants experienced long wait times. It took 2 months, after that 30 minute debacle, to sort everything out. We had to email out tickets by hand, fix broken transactions and explain to our clientele how this happened. At this moment, we realized that we needed to identify our rate determining step and have a governor on the registration process,  i.e. a stop sign in case we ever again exceed our limits.