Healthcare.gov technology stack (infographic)

"I can tell that this system consists of a JBoss Application Server with data access components and RESTful web services developed using Java. Given my prior experience with JBoss and Java, although they are great for middleware development, they’re known to be a bit slow."

I always had this non founded impression that something running on the JVM would be slow ... this author also. Anyone with data to back this impression ?

Re: Healthcare.gov technology stack (infographic)

#5

Post by patrickg_zill » Wed, Oct 30, 2013, 6:41 PM UTC

A friend analyzed the page and noted that they didn't minify or combine anything.

"One obvious reason is that they're serving unminified and unconcatenated Javascript and CSS files. A single page load causes 92 requests to the server, and they're not using a CDN for any of that.

They're also not setting the Cache-Control and Expires headers, so the browser isn't caching many of those files, including on 80k file full of response strings.

For the non-technical, this means the site is essentially killing itself. An optimized and properly tuned production website would load one (1) HTML document, one (1) CSS document, and one (1!) JS document, they're loading 92. "

Re: Healthcare.gov technology stack (infographic)

#6

Post by talmand » Wed, Oct 30, 2013, 6:43 PM UTC

hpritch5 wrote: post #3

Too bad I didn't get this contract...

I know what you mean, I could've totally made a failing website for $100 million max. I would have saved them money.

Re: Healthcare.gov technology stack (infographic)

#7

Post by pgrote » Wed, Oct 30, 2013, 6:44 PM UTC

Where are the links to IRS and social security admin? During the sign up process they verify tax return status and ssns of dependents including children?

Is that what CMS does?

Re: Healthcare.gov technology stack (infographic)

#8

Post by redthrowaway » Wed, Oct 30, 2013, 6:46 PM UTC

guiomie wrote: post #4

"I can tell that this system consists of a JBoss Application Server with data access components and RESTful web services developed using Java. Given my prior experience with JBoss and Java, although they are great for middleware development, they’re known to be a bit slow." I always had this non founded impression that something running on the JVM would be slow ... this author also. Anyone with data to back this impr…

It has nothing to do with "running on the JVM". The JVM is about as fast as you'll get any VM offering GC and running an IR like Java bytecode. It's only slow compared to compiled, native code (and even then nowhere near as relatively slow as it used to be), which no competing tech stack would be doing. It's much faster than Ruby, Python, etc.

That said, my experiences with JBoss haven't left me enamoured of it, and it certainly wouldn't be my first choice.

Re: Healthcare.gov technology stack (infographic)

#9

Post by [deleted] » Wed, Oct 30, 2013, 6:47 PM UTC

patrickg_zill wrote: post #5

A friend analyzed the page and noted that they didn't minify or combine anything. "One obvious reason is that they're serving unminified and unconcatenated Javascript and CSS files. A single page load causes 92 requests to the server, and they're not using a CDN for any of that. They're also not setting the Cache-Control and Expires headers, so the browser isn't caching many of those files, including on 80k file full…

[deleted]

Re: Healthcare.gov technology stack (infographic)

#10

Post by skyraider » Wed, Oct 30, 2013, 6:48 PM UTC

I think the interesting lesson here is that even marketplaces should be competitively constructed - i.e., there should be significant price-competitive pressure to deliver goods and services; just letting the government to facilitate marketplaces removes price competition from the marketplace itself.

I'm not suggesting that the government create a meta-marketplace for health insurance marketplaces. Just that it isn't as efficient as some people think to introduce a powerful federal competitor with 'unfair advantages' like public funding into the health insurance selection market.