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