Re: What is Performance -- JAVA400-L

Lo,

now we have some numbers, with a little bit more than guessing. If I 
understand correct this comparison includes the complete application. For 
further analysis we have now to seperate the "typical database workload" from 
the rest (this was the starting point). In my opinion most of the diffrence 
is the lightweight 5250 against dynamic generation of HTML pages and the job 
environment itself.

My estimate of 3 Times is based on three measurments:
- profiling of real java applications in load tests with mercury
- own Benchmarks (not made for this purpose, but for JDBC Driver Measurment) 
- own Benchmarks comparing embedded SQL against RLA in RPG

Dieter

On Freitag, 12. März 2004 14:23, Raikov, Leonid wrote:
> 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