[SATLUG] Affordable Healthcare websites
mspieth376 at gmail.com
Mon Oct 7 07:07:25 CDT 2013
Being in the Healthcare industry, this topic had come up a few days prior to this posting to which we were saying the same thing. The sites required for us to do things such as MU testing are horrible, (Now many aren't even online due to the government shutdown, although in my opinion they are actually more usable off than on) They are slow, error constantly and just plain out suck. If google, facebook and other sites worked as the governments do, no one would have a facebook account!
Here is an article on healthcare.gov which tells a little about how they developed it.
Healthcare.gov: Code Developed by the People and for the People, Released Back to the People
----- Original Message -----
From: "Borries Demeler" <demeler at biochem.uthscsa.edu>
To: "The San Antonio Linux User's Group Mailing List" <satlug at satlug.org>
Sent: Saturday, October 5, 2013 4:34:59 PM
Subject: Re: [SATLUG] Affordable Healthcare websites
Thanks so much, that's a very good explanation and makes a lot of sense!
When you say "scale the back-end out more" what you mean is to distribute
the load over multiple servers? I would assume that google, amazon, and the likes
already do this to a very high degree. But the database backend I can see being
a problem much more than the webservers, especially if there are some weaknesses
in the DB query code design. Glad to hear it was an avoidable problem by choosing
the wrong platform.
On Sat, Oct 05, 2013 at 04:27:05PM -0500, Kernel Architect wrote:
> Hi Borries,
> While I am not 100% sure about the back-end architecture of the websites, I
> am pretty sure that they are using Linux with healthcare.gov, which is the
> backbone of the whole ACA operation. According to netcraft, they are using
> Linux and Akami (as their CDN).
> With that said, in situations like this, it isn't the servers that crash
> per se. A site like this (or like the various state exchanges) are going to
> be heavy on the database usage side, and that is really where the slowdown
> or glitches would start to appear. No website launch is perfect, especially
> when you take a hit of 5-7 million people on the FIRST DAY! Mind you, many
> of these aren't just people coming to read some text. They are starting the
> process of signing up for healthcare coverage, so their load extends beyond
> the static content on the front page and onto the dynamic (database driven)
> content throughout the site and sign up process.
> So, bottom line is that from what I can see, they already used Linux and
> the biggest CDN out there (Akami). They just couldn't handle the massive
> amount of people coming to the site all at once which is all to common for
> a large website launch like this. There really was no way to avoid this
> (other than a staged rollout which would have been difficult), but I
> understand that the engineers are now going to scale the back-end out more
> to accommodate for the increased demand here soon. That should alleviate
> most of the problems. Keep in mind that they were planning for
> approximately 11 million people to sign up over a period of 6 months. That
> is less than two million per month. 5-7 million turned out on day one! That
> speaks volumes about what the site was able to withstand (it never actually
> crashed) and what the anticipated vs actual demand/interest in the ACA is.
> On Sat, Oct 5, 2013 at 4:11 PM, Borries Demeler <demeler at biochem.uthscsa.edu
> > wrote:
> > Does anyone have any insight why the websites for the new health insurance
> > exchanges were unable to handle the high demand? (NB: no flames about
> > Obamacare please). I am curious if this is a function of Microsoft web
> > servers
> > vs. Linux web servers. It seems to me that if you have enough bandwidth and
> > a fairly recent computer with Linux having sufficient memory and multi-core
> > architecture it would be quite difficult to bring such a server down. To
> > phrase it
> > differently, how much demand would you need to bring such a server down? A
> > typical LAMP configuration should be able to hold up to pretty extreme
> > demands.
> > On the other hand, this may not hold for even new versions of Microsoft
> > webserver,
> > but I don't know this. Is this an issue that could have been avoided by
> > using
> > Linux instead? Does anyone have any insights here?
> > -b.
> > --
> > _______________________________________________
> > SATLUG mailing list
> > SATLUG at satlug.org
> > http://alamo.satlug.org/mailman/listinfo/satlug to manage/unsubscribe
> > Powered by Rackspace (www.rackspace.com)
> SATLUG mailing list
> SATLUG at satlug.org
> http://alamo.satlug.org/mailman/listinfo/satlug to manage/unsubscribe
> Powered by Rackspace (www.rackspace.com)
SATLUG mailing list
SATLUG at satlug.org
http://alamo.satlug.org/mailman/listinfo/satlug to manage/unsubscribe
Powered by Rackspace (www.rackspace.com)
More information about the SATLUG