RE: What is Performance

I once used IBM Workload estimator to compare the "traditional" and
"Webcommerce" workloads. I know how rough such estimates are, but
nevertheless I was interested in what IBM had to say on the subject.
Webcommerce came up 64 times more resource-consuming than RPG.

In my personal experience, the difference can be 10 times rather than 64
time, provided that Java project is immaculately designed and
implemented and RPG design is what it is.

But data mapping is a sure killer.

Lo 

-----Original Message-----
From: Dieter Bender [mailto:dieter.bender@xxxxxxxxxxxx]
Sent: 12 March 2004 11:38
To: Java Programming on and around the iSeries / AS400
Subject: What is Performance


Joe,

> Now, since RPG is anywhere
> from 10 to 100 times faster than Java in typical database
transactions,

thats one of the misteries, that might have been true some years ago, or
that 
might be true for a liitle 170. But today on recent hardware its simply
not 
the truth.

For simple transactions (like read a record, or do one single update)
there 
might be an advantage for rpg, but you have to pay a price for this, you
have 
to code every line by hand and changes in database or retrival logic has
more 
maintenance afford, compared to modern languages like java, where you
can use 
mapping tools for instance. This advantage would be in the range of 3 to
5 
times faster for rpg to well done java code. If you get 10 to 100 times,

there must be a problem with the design of the java code.

For complex transactions java might be even faster than rpg, if you use 
multithreading in java to get benefit of parallelism (then you must not
use 
EJBs, so its a conclusion that EJBs are not the solution for each
problem). 
If you want to use this effect in the future, its another conclusion,
that 
you should not use RPG calls for simple transactions.

Putting this together today a rpg solution might be about 3 times faster
for 
one user compared to a well designed java application doing comparable
work. 
Besides the fact (some like others not) that green screen is diappearing
lets 
have a look how applications scale and let's begin with 5250.

Every additional user gets a job of its own and the 5250 rpg stuff
(COBOL as 
well) scales linear up to the limits of the hardware. The single process
has 
a very small footprint and this applications scale so good, that ibm
invented 
CFINT to let the custumor see that a big as400 is faster than a little
250.

Thats very diffrent to the Application Server Environment of WebSphere
or 
Tomc@ or JBoss. All users share the same Job (ore one per JVM instance).

Within this Job the work is splitted into multiple threads by the
container 
itself to get scalability. One easy way to increase the number of jobs,
to 
improve scalability of those applications is to increase the number of
JVMs. 
One way is to have multiple instances of the same Server (depends on
Server 
howto) or to use diffrent Servers (EJBs is one variant to do this
without too 
much coding).

The footprint of the java environment is not as lean as the rpg
environment, 
so that ibm decided, that they don't need CFINT to limit scalability.
Typical 
as400 shops will get comparable hardware for comparable prices for their

needs of scalability for java applications running on as400. If they mix

their java workload with their 5250 workload, this might not be true,
but is 
a marketing issue.

And now lets have a closer look at the java rpg mix and ist scalability.
As 
Joe showed up in his little example the rpg call puts some overhead to
the 
database workload, I have my "good day" let us forget it. The
application 
might be a little bit faster, than the pure java solution, but it will
need 
the needs of the customer anyway, if he has appropriate hardware both
will be 
in subsecond region. (BTW, if a java application has longer response
times 
for a single user, then you must have a look to other problems. Pulling 
10.000 record in one Vector is not very difficult in java, but it might
need 
10 sec. for instance).
Putting more concurrent user to the workload is happening in a fixed
number of 
jobs and all application containers solve this problem by increasing the

number of concurrent threads in their Job (= JVM). Main factor which
limits 
scalability in this approach is synchronisation, regardless how many
power a 
processor has, there is a limit you can't jump over. If the processor is

strong enough the limit of synchronisation will be reached. (a similar
effect 
is knonw from record locks in a database).
Synchronisation is done by the container itself and by the java
programmer 
using synchronized, or synchronise or by referencing methods wich are 
synchronized (logging for example!!!). And each call to rpg puts 
synchronisation to the application. (you should use a H spec with thread

*serialize, this synchronizes on the module: only one method of the
module 
can run at one time and the next waits until its finished). This 
synchronisation for the rpg stuff happens on job level; that means using
jni 
to call rpg is worse for scalability. Using the toolbox call classes,
the 
AS400 Object, representing the connection to another server Job is the
scope 
for synchrionisation. But whatever you do, the mixed environment
increases 
your synchronisation overhead significant and is part of scalability.

BTW Assemble was replaced by other langusages when the performance
punichment 
was in the region of factor 3.

Dieter



> _______________________________________________
> This is the Java Programming on and around the iSeries / AS400
(JAVA400-L)
> mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/java400-l
> or email: JAVA400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/java400-l.

-- 
mfG

Dieter Bender


DV-Beratung Dieter Bender
Wetzlarerstr. 25
35435 Wettenberg
Tel. +49 641 9805855
Fax +49 641 9805856
www.bender-dv.de
eMail dieter.bender@xxxxxxxxxxxx

_______________________________________________
This is the Java Programming on and around the iSeries / AS400
(JAVA400-L) mailing list
To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.