Link from Miguel Paraz:
Short URL: http://sachachua.com/blog/p/1193
The company I work for runs a large, high-profile web site with users
all across the world and delivers them large amounts of streaming
media content plus textual stories. You might guess therefore that
this is a news website, frequently updated throughout the day, and
delivering content 24×365. No names, or course, for obvious reasons.
We have a big, custom, Java content management system (based on a
framework from a proprietary vendor as it happens, but could just as
well be EJB/J2EE for all that it matters in the context of this
argument) and for deployment we run our website using Java app servers
on Solaris behind Apache.” If you were going to take such a site from
1000 users, to 10,000 users, would you be able to do it using this
kind of setup?
“It is all hugely expensive to license and to run, and it’s not very
scalable. We’d like to up our userbase from several tens of thousands
to ten times that number – but the cost of scaling the Java/Solaris
infrastructure is not trivial, because the Java servlet architecture
costs too much in memory and execution time (creating several 100Ks of
in memory objects for each logon is expensive stuff!). On current
hardware we can support only 1200-1500 concurrent logins and scaling
up requires a new app server (eg 1 processor + 1GB RAM) and a $20K
software license for each additional 600-750 concurrent logged in
users. And in today’s ‘cost per active subscriber’ economics it
doesn’t add up – we cannot justify the present cost structure, by any
rational measure, even before we try to scale it up.
So we’re thinking of chucking it out and replacing it with a largely
static site that is generated (written out to cache) from a new,
simpler content management system. The few dynamic elements would be
assembled using simple PHP scripts, frontending our existing Oracle DB
server. We reckon we could serve vastly higher numbers, ten to a
hundred times as many, of users on the same (or cheaper!) hardware:
and it would be simpler by far to build and maintain and support.
I, personally, believe that the benefits of the Java system (rapid
prototyping, development) are not important when large scale
deployment is the issue. I am (as a user) fed up with large, poorly
performing Java-based websites. My beef is not about Java the language
though – it’s a question of appropriateness. Fifteen years ago we’d
prototype in Smalltalk and then code for deployment in C, and I feel
the same applies here. The economics of the noughties do NOT support
spending massive amounts of money on web infrastructure, unless the
transactional revenue justifies it. Of course, most businesses
generally don’t justify it, in my opinion.
Our outsourcing partner who supports and maintains the architecture
thinks we are crazy. Putting their potential loss of revenue aside
they are hugely concerned that we’ll not be able to support what we
create. They are seriously against this idea.
I remember, prior to Java & the like, supporting simple CGI websites
with tens & hundreds of thousands of users off of cheap FreeBSD
systems, and we didn’t have to pay an outsourced partner to do it.