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.
[RELATED:Ailing Obamacare website to get a "tech surge"]
"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."
Third-party monitoring components used on the Healthcare.gov site include Google, Chartbeat and Pingdom, according to Compuware's blog written by staff engineer Andreas Grabner, who notes "all these third-party components need to load JavaScript files that impact the initial page load time."
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 registration page for the site is "actually a very bad example of some of the well-known practices of Web Performance Optimizations," according to Compuware's Grabner. "It seems they forgot to merge CSS and JS files together as they are currently loading about 55! Individual JavaScripts files and 11! Individual CSS files!" Compuware makes specific recommendations on how these could be merged, adding "especially because many of them actually belong logically together as well, e.g.: jQuery and JQuery Plugins." Grabner adds that "loading too many small JS and CSS files together instead of merging them together results in "too many roundtrips to the web server." Uncompressed versions of images is also resulting in inefficiencies for the website, he notes.
- 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.
- Filling out an application on the site now "uses a lot of JavaScript to deal with validating input as well as presenting the results," Grabner's blog points out. He notes that usage of third-party JavaScript libraries is very common as it takes a lot of work off user interface developers. But sometimes this doesn't work out well, and "looking at the JavaScript hotspots on that particular page shows some very significant hotspots by click event handlers for things like Add Deductions, Annual Income Information or simply clicking on the Accept Warning and Continue. Response times of up to 7 seconds were mainly caused by these JavaScript frameworks that iterate through the whole DOM to identify those elements that need to be modified or not." Grabner's blog notes that depending on the browsers JavaScript engine, this can have a significant performance impact.
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, and 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: emessmer@nww.com
Read more about infrastructure management in Network World's Infrastructure Management section.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.