avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Oberhack" <deve...@softwarefabrik.biz>
Subject Requirements: scalability, stability and multiple JVMs with Merlin?
Date Wed, 28 Apr 2004 10:45:35 GMT
Hi Alex, Nader,

first of all: Thanks fort he excellent analysis Nader. You are really
giving a great outline what one could do!

> Ok you have me totally depressed and thinking this is near impossible
> now :-(.  

The question is, whether really want to do that all! Let's have a look
at the requirements first.
Let's assume, we want to build business applications. And let's also
assume, that we really want to build enterprise level applications. And
finally let's assume, that we would like to build enterprise level
applications for the financial industry.

And all this should be done with Java.

Ok. Now let's have a look at the scalability requirements and the myths
how to solve them. The normal way the whole industry is thinking now is,
that we "really"!! need distributed facilities - like EJBs or jinni
or... - to really serve thousands of concurrent users. Is that true? No!

The reality. I'm coaching a "payments" application in a bank. Completely
build in Java and JMS. That's it. It is in production since six month.
They are serving 15 Millions business transactions on one machine. They
have run test in which they have served 50 million business transactions
a day. This is all on one machine! Ok - it's a IBM mainframe - but had
ported the app on a NCR machine in 14 days - with no performance

If I mean "business transactions" I mean that there are 5 or 10 times
more technical database transactions! Aggreed: When they started in 1998
the performance hit between Java and Cobol was 1:20. Today it's 1:1.8!
And now IBM had announce an Java Co-Processor for IBM mainframes and
stated, that they will overrule COBOL performance now with Java!

At the same time I was working for an other bank. They where developing
a new architecture for all future developments. They tried to build that
on an EJB application server on a IBM mainframe. To get the appserver
run, they needed at least 8 GB! Of RAM - to get apps run they stated to
need 16 GB of RAM!!. So they installed the appserver with 16 GB of RAM
on a 1980 Mips IBM mainframe. Exclusively running for us. Now to the
results: After the appserver was started, we had a 10% CPU consumption
without any applications running. At the top, with no database access,
only stateless SB, we reached about 200 trx/sec. This is not bad. At the
low end, we had 15 trx/sec with CMP and 2PC. Technical transactions!!

So do we need distribution for scalability? I would say now!

Do we need distribution for fault tolerance reasons? This question is a
bit more difficult. But to shorten the email a bit: I know COBOL /
mainframe applications, which serves 60.000 users on a single machine.
Does COBOL support distribution? Does Cobol need that for fault
tolerance reasons? No!

Why that? Because mainframes today are 100% stateless! This might be not
the solution for the Java world - but just to have something to think

So do we need distribution to achieve fault tolerance? Not necessarily!

Do wee need distribution at all? Hm - I'm afraid to say: Yes! There is
one point if we want to open up our applications to the outside / not
enterprise internal world. For security reasons we have to isolate the
webserver in a DMZ - physically decoupled from business applications.
But do we really need EJB, Jini, CORBA, ... for that? We should think
about that!

My conclusion: we have to think about fault tolerance as the main issue.
That's it. Than let's switch to application side and solve business
semantics - that's the far more appealing part in the business
application arena! That's why Merlin rocks - a clear separation of
business logic and technical issues is possible by design!

Ok Alex - no reason for resignation :-)

All the best


To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message