Re: What is Performance

Joe,

I've waited some days to answer to your statement, to come back to a 
discussion without emotions. I will try to avoid statements (on rpg or 
WebSphere) which might be misinterpreted as condescending the work or 
knowlegde of other people. It was never intended by me to do so.

On Freitag, 12. März 2004 13:58, Joe Pluta wrote:
> > From: Dieter Bender
> >
> > 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.
>
> Prove it.

Joe, this cant be the rule of the game. In your originating posting  you 
claimed performance benefits of rpg business logic components of 10 to 100 
times. It can't be my work to prove that this numbers are by far too high.

>
> > 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.
>
> Prove it.

Performance capabilities reference gives estimates that are by far more 
optimistic from the java perspective, so I have degraded their estimates to 3 
to 5. This would be a little bit worse than numbers published for comparisons 
on other platforms (Java compared to C on Unix for instance). 


> > And now lets have a closer look at the java rpg mix and ist
>
> scalability.
>
> (snip of a bunch of stuff about how calls to RPG aren't scalable.)
>
> Dieter, your arguments are unsubstantiated.  You base them on some
> assumptions about synchronization that simply aren't proven.  For
> example, in my architecture each session gets its own job and
> communicates with the JVM via data queues.

To make it simple let us discuss this on your example for the programm call 
(the counter). If you would use this rpg counter to put the number of 
transactions on every JSP increasing it by 1 for every JSP shown for the user 
in his session, you would have to put the AS400 Connection for the programm 
call in the session object of your Web Application, otherwise you would loose 
the state of the rpg counter programm from one call to the other.
Putting the AS400 Object in the session object would be enough to limit the 
scalability of your Web Application. You would need an AS400 Object of its 
own for every users session and could not use Connection Pooling for the 
AS400 Objects and the memory of the application container has to hold this 
large objects; by this the memory of the application Container sets a limit 
to the number of users you can handle. (These effects are described in the 
performance recommendations for the application servers).
Effective load balancing would not be possible, you can't get the session 
objects serializable, as long as they contain the AS400 Objects.
With such a design you would not survive a design review by an independant 
third party in case of trouble with your custumor on the scalability of your 
application. (I took part on such reviews as consultant for a softwarehouse 
and we came in problems, because they stored the JDBC Connection in the 
session).

>
> In any case, I no longer will respond to your general statements about
> performance until I see some working code that supports your claims.
> Please feel free to write some code that backs up your statements and
> present it here.  Then we can talk.  Until then, it's all supposition
> and a waste of time.

Joe, if performance issues and scalability issues where as easy as this, we 
didn't have any of them. Especallly scalability is a number you will get for 
a whole application, after you have finished it and my experience in long 
years is (BTW for rpg apps too): there comes the day it is too slow and the 
requirement will be: make it faster, or let it scale better. That's one of 
the reasons, why I feel better in the main stream of java. Often there is no 
need to do all things diffrent on as400.

Dieter

>
> Joe
>
> _______________________________________________
> 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