|
David, Maybe your application is doing some serious processing. Otherwise the response times sound pretty bad. I was just testing a Web based Purchase Order Inquiry application written in RPG, handling 20 concurrent client threads, against a small sample database, on a model 800, accessing PO Header, Line Item Detail, Vendor Information, Shipping Information, and other control files, and generating an HTML page containing an iFrame, which spawned a second request to display a printable Purchase Order. Our model 800 probably costs 1/10 to 1/20 the price of your model 825, but the program was handling 16 requests per second. A DSL line over the Internet separating my workstation from the server was slowing the responses. The RPG program handling the requests never used more than 6% of the CPU on a production box, and consumed an average of 5 milliseconds of CPU time per request. No HTTP Errors. Every request was handled. See the detail report below. Nathan. Overview ============================================================================ ==== Report name: 3/12/2004 1:51:45 PM Run on: 3/12/2004 1:51:45 PM Run length: 00:01:01 Web Application Stress Tool Version:1.1.293.1 Number of test clients: 1 Number of hits: 968 Requests per Second: 16.14 Socket Statistics ---------------------------------------------------------------------------- ---- Socket Connects: 986 Total Bytes Sent (in KB): 496.85 Bytes Sent Rate (in KB/s): 8.28 Total Bytes Recv (in KB): 2515.67 Bytes Recv Rate (in KB/s): 41.93 Socket Errors ---------------------------------------------------------------------------- ---- Connect: 0 Send: 0 Recv: 0 Timeouts: 0 RDS Results ---------------------------------------------------------------------------- ---- Successful Queries: 0 Script Settings ============================================================================ ==== Server: 216.250.76.210 Number of threads: 20 Test length: 00:01:00 Warmup: 00:00:00 Cooldown: 00:00:00 Use Random Delay: No Follow Redirects: Yes Max Redirect Depth: 15 Clients used in test ============================================================================ ==== localhost Clients not used in test ============================================================================ ==== Result Codes Code Description Count ============================================================================ ==== 200 OK 968 Page Summary Page Hits TTFB Avg TTLB Avg Auth Query ============================================================================ ==== GET /etl/fms/pur/04CLNCA42391/ 488 550.47 552.43 No No GET /etl/fms/pur/04CLNCA42391/ 480 578.58 922.07 No No ---------------------------------------------------------------------- message: 1 date: Fri, 12 Mar 2004 08:39:37 -0700 from: "David Morris" <David.Morris@xxxxxxxxxxxxx> subject: RE: EJB versus RPG/COBOL Joe, I spent this week load testing performance of a large scale java-based system running on the iSeries. The average across the system response on RPG green screen apps has historically been about .5 seconds. The results using jMeter for a mix of 10 users hitting a mix of the same the same applications (actually much more functional) continuously was .71 seconds with an overall load on the system of about 20%. This load allows a weeks worth of transactions to be put through in 30 minutes. Increasing the load to 25 continuous simultaneous users results in 2.1 second response with about a 40% load but a weeks worth of transactions would have been completed in about 20 minutes. Pushing it up to 50 users to see if we could overwork the machine performance dropped to about 9 second response at 65% utilization. Actual concurrency testing with live bodies also seems to back up these results. These tests were run during slow business hours but still had to contend with production work. This system is somewhat constrained by memory and to a lesser extent disk arms. You mention simple panels and I can assure you that is not the case here. The database this runs against contains tables with > 100,000,000 records and the database I/O for several of these scripts involves processing/summarizing > 30,000 records. The heavy lifting in those cases is done by SQL, which is nice because the system puts those on separate threads that help fully utilize the CPU. This site is running Tomcat/Hibernate/iBatis on a low-end 825 and replaces a mixture of customized Software 2000 and custom ERP systems. I haven't had a chance to do any performance tuning so I expect that these numbers will get better. Still if I took 10-100 times RPG performance these applications would not work. David Morris >>> joepluta@xxxxxxxxxxxxxxxxx 3/11/2004 7:05:33 PM >>> And it required the bloated overkill of EJBs to make multiple-second response time for a simple inquiry panel the norm. On the other hand, my clients get subsecond response time using RPG and Java on REAL business applications. And since the point evidently wasn't clear amongst all that LOFLOL, my example program was showing that the Java->RPG call interface takes two milliseconds on a tiny little Model 270. Now, since RPG is anywhere from 10 to 100 times faster than Java in typical database transactions, that means that Java/RPG architecture will handily outperform EJBs. If you want to do some real comparisons of performance, I'm willing to discuss it. But if you just want to take potshots at RPG, I advise you to find another list. Joe ------------------------------ message: 2 date: Fri, 12 Mar 2004 10:16:00 -0600 from: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx> subject: RE: EJB versus RPG/COBOL > From: David Morris > > I spent this week load testing performance of a large scale java-based > system running on the iSeries. David, I'm not saying your application doesn't perform well. However, you're not really providing any equivalence figures. How many green screen users can you get going? Do they see the same degradation when you have 25 users? Or 50? You need to compare apples to apples to get meaningful numbers. Also, there is a difference between inquiries and transaction processing. SQL-based inquiries, especially the larger they get, blur the distinction between Java and RPG because both end up spending most of their time in the SQL engine. I've always said that for pure inquiries (especially ad hoc), SQL performs quite impressively, and that savings is then passed on to whatever your application is. But for real transactions, where processing is done on individual records and rules are based on database flags, RPG outperforms Java by the 10-100 times figure I specified. Joe ------------------------------ message: 3 date: Fri, 12 Mar 2004 11:16:37 -0500 from: "Rohr, Rob" <rjrohr@xxxxxxxxxxxxxxxxx> subject: exporting .JAR files along with .EAR file for WAS I have a Enterprise Application Project with a web project that I am exporting to Webpshere V5. I also have a few .JAR files the project uses. How can I (or can I?) bundle up these additional .JARs so that they are deployed in the .EAR and don't have to add them specifically to the server under the environment options (ws.ext.dirs) tab? Rob ------------------------------ message: 4 date: Fri, 12 Mar 2004 10:24:10 -0600 from: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx> subject: RE: Mixed RPG/Java performance (EXAMPLE CODE) > From: Bartell, Aaron L. (TC) > > Because I am purely curious, what exactly are the points that make Java a > poor language for business logic? The biggest issues with Java itself is the data conversion. EBCDIC->ASCII, character to String, and especially numeric to BigDecimal, all of these cost a lot in terms of ovberhead. The BigDecimal class is a notoriously poor performer (so bad that IBM created its own). EJB adds a whole new level of overhead. Since the entire bean needs to be populated, that means you have to convert every field, even if you don't need it. At least with a JDBC approach you can convert only those fields you are using. With EJB, you have to convert the entire customer master in order to access a single flag. Most Java programmers have no clue about this, and since they tend to test on dedicated fast Wintel machines with lots of RAM, the problems don't actually show up until they make it to production. Joe ------------------------------ message: 5 date: Fri, 12 Mar 2004 09:37:11 -0700 from: "David Morris" <David.Morris@xxxxxxxxxxxxx> subject: RE: EJB versus RPG/COBOL Joe, These are transaction programs -- from my message "This load allows a weeks worth of transactions to be put through in 30 minutes." About 15,000 loads containing about 100,000 individual products were processed against 500 checks being process, matched, sent to A/R and G/L in this test. On our old 730, the RPG version of these applications had that server pegged at 90% plus utilization. Throughput was poor due to the volume of transactions. On this 825, the RPG based code only hits about 30% CPU utilization. My testing shows that this Java workload will push that up to about 35% CPU utilization -- more memory would increase this number. Since this was a load test, I kept pushing up the user counts to see where the ceiling was and it comes in at about 40-50 simultaneous users continuously hitting the submit button. David Morris >>> joepluta@xxxxxxxxxxxxxxxxx 3/12/2004 9:16:00 AM >>> > From: David Morris > > I spent this week load testing performance of a large scale java-based > system running on the iSeries. David, I'm not saying your application doesn't perform well. However, you're not really providing any equivalence figures. How many green screen users can you get going? Do they see the same degradation when you have 25 users? Or 50? You need to compare apples to apples to get meaningful numbers. Also, there is a difference between inquiries and transaction processing. SQL-based inquiries, especially the larger they get, blur the distinction between Java and RPG because both end up spending most of their time in the SQL engine. I've always said that for pure inquiries (especially ad hoc), SQL performs quite impressively, and that savings is then passed on to whatever your application is. But for real transactions, where processing is done on individual records and rules are based on database flags, RPG outperforms Java by the 10-100 times figure I specified. Joe ------------------------------ message: 6 date: Fri, 12 Mar 2004 16:37:47 -0000 from: Colin Williams <colin.williams@xxxxxxxxxxxx> subject: RE: exporting .JAR files along with .EAR file for WAS Rob, Add them as dependant jars to the EAR file. If they are utility projects in WDSC, just add that project to the EAR file by editing the deployment descriptor in the EAR file. If they are already JAR files, just copy and paste them directly into the EAR project. Once you've done that, click properties on each project in that EAR project, and then select dependant jars. You should see all the jars you added to the EAR project listed, just select the ones you want to apply for each project. This way, you can deploy your EAR, which will also deploy the jars with it, and not modify the servers classpath at all. Cheers Colin.W -----Original Message----- From: Rohr, Rob [mailto:rjrohr@xxxxxxxxxxxxxxxxx] Sent: 12 March 2004 16:17 To: 'JAVA400-L@xxxxxxxxxxxx' Subject: exporting .JAR files along with .EAR file for WAS I have a Enterprise Application Project with a web project that I am exporting to Webpshere V5. I also have a few .JAR files the project uses. How can I (or can I?) bundle up these additional .JARs so that they are deployed in the .EAR and don't have to add them specifically to the server under the environment options (ws.ext.dirs) tab? Rob _______________________________________________ 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. This e-mail has been sent by a company of Bertram Group Ltd, whose registered office is The Nest, Rosary Road Norwich NR1 1TF. This message, and any attachments, are intended solely for the addressee and may contain privileged or confidential information. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. If you believe that you have received this email in error, please contact the sender immediately. Opinions, conclusions and statements of intent in this e-mail are those of the sender and will not bind a Bertram Group Ltd company unless confirmed in writing by a director independently of this message. Although we have taken steps to ensure that this email and any attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. ------------------------------ message: 7 date: Fri, 12 Mar 2004 10:40:43 -0600 from: "Daniel Feather" <DFeather@xxxxxxxxxxxxx> subject: RE: exporting .JAR files along with .EAR file for WAS In a .WAR you can put them in the WEB-INF/lib directory. I haven't dealt that much with .EAR's, but I am sure there is something similar you can do there for the same situation. Dan Feather Silhouette/PinPoint R&D Programmer Jack Henry & Associates, Inc. dfeather@xxxxxxxxxxxxx -----Original Message----- From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of Rohr, Rob Sent: Friday, March 12, 2004 10:17 AM To: 'JAVA400-L@xxxxxxxxxxxx' Subject: exporting .JAR files along with .EAR file for WAS I have a Enterprise Application Project with a web project that I am exporting to Webpshere V5. I also have a few .JAR files the project uses. How can I (or can I?) bundle up these additional .JARs so that they are deployed in the .EAR and don't have to add them specifically to the server under the environment options (ws.ext.dirs) tab? Rob _______________________________________________ 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. ------------------------------ message: 8 date: Fri, 12 Mar 2004 17:58:30 +0100 from: Dieter Bender <dieter.bender@xxxxxxxxxxxx> subject: Was What is Performance was EJB was mixed Design.... Joe, come down now! Joe today 16:29:14 It has been shown repeatedly in this and other places that RPG runs much faster than Java for database I/O. If you think this is wrong... Joe today 17:16:00 Also, there is a difference between inquiries and transaction processing. SQL-based inquiries, especially the larger they get, blur the distinction between Java and RPG because both end up spending most of their time in the SQL engine. I've always said that for pure inquiries (especially ad hoc), SQL performs quite impressively, and that savings is then passed on to whatever your application is. Dieter ------------------------------ message: 9 date: Fri, 12 Mar 2004 11:20:42 -0600 from: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx> subject: RE: EJB versus RPG/COBOL > From: David Morris > > On our old 730, the RPG version of these applications had that server > pegged at 90% plus utilization. Throughput was poor due to the volume > of transactions. On this 825, the RPG based code only hits about > 30% CPU utilization. My testing shows that this Java workload will push > that up to about 35% CPU utilization -- more memory would increase this > number. These are unique findings, David. I'd be very interested now to see how the original RPG code was written and what it did. It's my contention that properly written RPG code will by far outperform Java code, and I find it very difficult to comprehend a database operation where Java matches RPG. One way is to use set-based updates. If you transform record-by-record processing to set processing, you will see performance improvements, but these are due to the nature of SQL, not Java. How are you doing your updates? Single record using JDBC? Set at a time SQL processing? Joe ------------------------------ message: 10 date: Fri, 12 Mar 2004 11:13:39 -0600 from: Glenn Holmer <gholmer@xxxxxxxxxxxxxx> subject: Re: Mixed RPG/Java performance (EXAMPLE CODE) Joe Pluta wrote: > Most Java programmers have no clue about this, and since they tend to > test on dedicated fast Wintel machines with lots of RAM, the problems > don't actually show up until they make it to production. Ouch! does that mean I'm in the Java ghetto? If I worked that way, I'd be out on the street. We get it about EJBs, Joe. Talk to a lot of Java programmers and they'll tell you the same thing; they've definitely fallen out of fashion. That doesn't make Java a Bad Language(tm). -- ____________________________________________________________ Glenn Holmer gholmer@xxxxxxxxxxxxxx Programmer/Analyst phone: 414-908-1809 Weyco Group, Inc. fax: 414-908-1601 ------------------------------ message: 11 date: Fri, 12 Mar 2004 11:35:54 -0600 from: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx> subject: RE: Was What is Performance was EJB was mixed Design.... > From: Dieter Bender > > come down now! What don't you understand? For transactional I/O, RPG runs faster than Java. You don't believe it, write a program and test it. As to SQL processing, when both RPG and Java use SQL for large inquiries, most of the processing is done by the SQL engine, thus minimizing the effect of the Java overhead. A simple inquiry using SQLRPG will still run faster than the same application in Java, but the percentage performance improvement will not be as high as a transactional program. Again, don't believe me? Write an example and prove it. Joe ------------------------------ _______________________________________________ This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) digest 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. End of JAVA400-L Digest, Vol 2, Issue 90 ****************************************
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
