An apologetic Obama administration has had technical people working around the clock to address problems with its Healthcare.gov website, which has been unable to cope with visitor traffic since launching on Oct. 1. One vendor, Compuware, is also doling out some free insights into what's wrong with the Obamacare site after remotely running some of its own application-performance management (APM) tests.
"One that stood out as a problem is Pingdom," says John Van Siclen, general manager at the Compuware APM business unit. As a third-party monitoring service integrated in as a component of the Affordable Care Act website, Pingdom doesn't seem to be used well at Healthcare.gov, contributing to the site's slowness. "It's not keeping up."
Compuware says it ran its free tool, Ajax Edition, and also its cloud-based APM service, to get a bead on what can be seen remotely about Healthcare.gov's performance as related to both how the site's software components interact with each other and the incoming traffic of user requests from across the country.
Healthcare.gov was supposed to be the site where buying health insurance was going to be as easy for the public as purchasing an airline ticket online, as President Obama once put it. But now, Health and Human Services Secretary Kathleen Sebelius is expected to soon join the site's main contractors, including CGI and QSSI, to testify before a House panel about the site's technical problems and how they might get fixed.
Here's more on Compuware's observations about what's wrong with the site:
- Loading the Healthcare.gov home page takes a very long time by the standards of other healthcare sites to download just the 59K initial HTML document, which is "probably caused by bandwidth constraints on its web server, as most of the time this is contributed to the server response time and not the network." There's a need to optimize the use of third-party components and make sure the initial HTML page can be served faster from the web servers.
- The website's MyProfile page revealed the "most obvious end user performance impact," according to Compuware. "We could see a 16.8 second server response time for an AJAX call that returned some basic user information for the logged in user. The end user has to sit and wait until that AJAX request finally completes so that the page is fully operational." Grabner's blog adds: "What's even more interesting is that every interaction on that MyProfile page re-sends this AJAX Request returning basically the same information again without caching it. Taking a closer look at the actual content that is returned, it seems that about 95% of the content is always the same (e.g.: name, phone number...). There is only one field in that returned JSON object that actually changes." Compuware says caching could help optimize this part of the site's behavior.
Van Siclen says the analysis of the Healthcare.gov website by Compuware suggests that the contractors creating the site may have sought to cut a lot of corners and turned to open source to save money.
It's clear that the testing before the launch was "spotty at best," Van Siclen adds.
Compuware's own cloud-based APM tests show how traffic through the Internet is flowing to the site from across the country.
Looking at fifty locations in the U.S., such as Chicago, Dallas, Boston and the other major cities, there are "dramatic differences" in how user traffic is reaching the healthcare.gov site in Washington, Van Siclen says. "The traffic from the Midwest is five times slower than traffic from the Northeast and West," he says. There are likely latency issues in all this that have to be studied further. Compuware APM testing remotely did not look at back-end functions, such as how internal databases or other integrated services used by Healthcare.gov were working.
Estimates on the cost of the Healthcare.gov site roll-out are now pegged at more than $400 million, andA work to try and fix its problems is ongoing and likely to add more costs. Fresh criticism, such as complaints the pricing of insurance policies is off the mark on Healthcare.gov, seems to grow each day.
HHS Secretary Sebelius, interviewed by CNN yesterday, admitted tests the government oversaw prior to the Oct. 1 launch deadline of the website did reveal that Healthcare.gov would crash with just a few hundred users on it. But she said the Obama Administration went ahead with the launch anyway because waiting was not an option.
"There are people in this country who have waited for decades for affordable health coverage for themselves and their families," she told CNN by way of explanation. She told CNN that the President wasn't informed about these problems, though.
As more about that will undoubtedly be hashed out in contentious hearings on Capitol Hill in the next few weeks, the main question is whether the federally-run website that is serving the 36 states that decided not to run their own healthcare exchanges will be working reliably before the end-of-year deadline for the Affordable Care Act mandate requiring everyone to have insurance or face penalties.
Van Siclen says he's fairly optimistic it will if the right decisions are made, and he notes he's seen commercial websites run by businesses face mammoth operational difficulties and recover, too. Major seasonal events in the U.S., ranging from Thanksgiving to Christmas shopping surges or the big Super Bowl game with advertising tie-ins, for example, have long brought challenges that strained websites beyond the ordinary. "We've also had customers that thought they'd have to throw out millions of dollars of code," he adds, but that's not always the case.
Ellen Messmer is senior editor at Network World, an IDG publication and website, where she covers news and technology trends related to information security. Twitter: MessmerE. E-mail: firstname.lastname@example.org
Read more about infrastructure management in Network World's Infrastructure Management section.
This story, "Why is the Obamacare Healthcare.gov Website So Sick?" was originally published by Network World.