|
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
