|
Joe, My apps are just a "tad" more involved that your sample. Not really a fair comparison (I couldn't tell if you were comparing or not). I'm not using any JSP right now, just servlets as CGI. My problem may be how I'm doing DB i/o, and I plan on posting a small bean that I'm using to see if anyone has any pointers. Brad > -----Original Message----- > From: Joe Pluta [mailto:joepluta@PlutaBrothers.com] > Sent: Thursday, March 01, 2001 4:54 PM > To: JAVA400-L@midrange.com > Subject: RE: Java and CPU > > > I guess it depends on your application, Brad. I just ran an > informal test > on my machine. I loaded my server from scratch, which took > about 45 seconds > or so of CPU time - it takes a while to load all that good > stuff. Then I > made 200 or 300 hits to my server, the total was about > another 30 seconds or > so. Let's see my results from here: > > QBASE SBS 2 0 2.2 0 .0 > LINLST BCH 2 50 3.6 0 3.6 > QPADEV0002 INT 3 20 .7 1 .0 0 .0 > QSYSSCD BCH 3 20 .3 0 .0 > QEJBSBS SBS 2 0 .0 0 .0 > DEFAULT_SE BCI 2 25+ 24.2 0 10.4 > QEJBADMIN BCI 2 25+ 58.1 0 .1 > QEJBMNTR ASJ 2 25 .0 0 .0 > > Note that LINLST is the RPG program actually servicing the > result. He does > all the actual database I/O. So let's see. I'm going to do > another 200 > hits. > > QBASE SBS 2 0 2.2 0 .0 > LINLST BCH 2 50 10.6 0 2.2 > QPADEV0002 INT 3 20 .7 2 .0 0 .0 > QSYSSCD BCH 3 20 .3 0 .0 > QEJBSBS SBS 2 0 .0 0 .0 > DEFAULT_SE BCI 2 25+ 44.5 0 6.6 > QEJBADMIN BCI 2 25+ 58.5 0 .1 > QEJBMNTR ASJ 2 25 .0 0 .0 > > Okay, 200 hits (actually, I lost count so I did an extra 40 > hits, so this > could be anywhere between 200 and 240 hits, but let's say 200 > for argument). > I was putting out the following screen, all data being read > from files on > the AS/400: > > Kenosha Weekday Inbound > Train #300 > Station Time > Kenosha ---- > Winthrop Harbor ---- > Zion ---- > Waukegan 4:58 > North Chicago 5:01 > Great Lakes 5:05 > Lake Bluff 5:10 > Lake Forest 5:13 > Fort Sheridan 5:16 > Highwood 5:19 > Highland Park 5:22 > Ravinia 5:25 > Ravinia Park ---- > Braeside 5:27 > Glencoe 5:30 > Hubbard Woods 5:33 > Winnetka 5:36 > Indian Hill 5:38 > Kenilworth 5:40 > Wilmette 5:42 > Central Street 5:45 > Evanston 5:49 > Main St. 5:51 > Rogers Park 5:54 > Ravenswood 5:59 > Clybourn 6:06 > Chicago 6:15 > > There are also a few buttons. What I did was page up and > down through ten > different schedules, and I did that 10 times, for a total of > 200 pages. > > So, we can see that I consumed 7 seconds RPG time, 20 seconds > server time > and pretty much zero administration time. Extrapolated to > your benchmark of > 7000 page hits, my application would consume about 700 seconds of HTTP > server time, and maybe 250 seconds of RPG server time. These > numbers are > less than 2/3 those of your CGI application. They're more > than 100 times > better in performance than your Java version, which doesn'teven do any > database I/O. > > Now, things that can greatly increase those numbers include > starting and > stopping server instances and creating new Java Server Pages. > The latter in > particular can cause lots of work, because they have to be unloaded, > compiled, and reloaded. Have you been making lots of changes > to your JSPs? > That number shows up in the QEJBADMIN number, I'm pretty sure. > > The other load might be from how you're "Java-izing". As you > can see, my > programs don't have nearly as much load per page - I'm > talking overhead of > less than 100 msec a page, while you're seeing closer to a 30 > seconds. I > don't know why, but you might want to start putting some > trace statements in > your code to determine where your bottlenecks are. > > Good luck! > > Joe > > BTW, for anybody who might wonder how to architect an RPG program that > performs so well as a web application, it's actually a > revitalized green > screen program. That means it runs in green screen using a > display file AND > as the server for the web, WITHOUT changes. Here's the same > program run > interactively: > > STNSTP-01 Stop Master List > 3/01/01 > SECJDP For Line: Union Pacific North Line > 17:46:24 > For Schedule: Kenosha Weekday Inbound > For Train: 00300 > > Station Time > Kenosha ---- > Winthrop Harbor ---- > Zion ---- > Waukegan 4:58 > North Chicago 5:01 > Great Lakes 5:05 > Lake Bluff 5:10 > Lake Forest 5:13 > Fort Sheridan 5:16 > Highwood 5:19 > Highland Park 5:22 > Ravinia 5:25 > Ravinia Park ---- > Braeside 5:27 > Glencoe 5:30 > > More... > F3=Exit F19=Previous F20=Next > > Pretty cool, eh? This is what I teach... > > <grin> > > > > -----Original Message----- > > From: owner-java400-l@midrange.com > > [mailto:owner-java400-l@midrange.com]On Behalf Of Stone, Brad V (TC) > > Sent: Thursday, March 01, 2001 2:35 PM > > To: 'JAVA400-L@midrange.com'; ign_list@ignite400.org > > Subject: Java and CPU > > > > > > This I found interesting. > > > > We have an AS/400 that is a web server only. We're running > CGI to do > > customer service online for multiple customer/catalogs. > Right now it's > > about 30 sites (all using the same 3 or 4 programs, > webfacing controled by > > config files, SSIs, etc..). > > > > Some CPU stats for the normal HTTP Server: (jobs entered > system 2/14/2001) > > Subsystem/Job Type Pool Pty CPU > > CSO BCH 2 25 1516.4 > > CSO BCI 2 25 .1 > > CSO BCI 2 25 .3 > > CSO BCI 2 25 69.0 > > CSO BCI 2 25 26.1 > > CSO BCI 2 25 727.4 > > > > Now, I have also have websphere running. I've been trying to > > duplicate this > > CGI system using servlets and and making progress (no > wonder I'm asking so > > many questions!). > > > > Anyhow Here's the CPU stats for the default WAS server that > is processing > > the servlets: (entered system 2/19/2001) > > > > Subsystem/Job Type Pool Pty CPU > > DEFAULT_SE BCI 2 25+ 2847.7 > > QEJBADMIN BCI 2 25+ 6203.9 > > QEJBMNTR ASJ 2 25 .1 > > > > The HTTP server has received about 7000 hits since it started on > > 2/14/2001. > > This server serves up those 30 sites and is available 24/7. > > > > The WAS server hasn't even broken a couple hundred hits > since it's only me > > testing when I have time (started on 2/19/2001). It's not > > available to the > > interent and I am the only developer on the box. > > > > The Java version of the application isn't querying customer > service data > > yet, I'm simply building the web pages. The CGI programs > run dynamic SQLs > > to select and display data depending on customer signon information. > > > > The numbers compared to just the default WAS server may be > close, but > > remember, it's doing about 1/100th of the work right now. > > > > Any thoughts, ideas, or otherwise? I'm really wondering > why so much more > > CPU is used. If I were to take my app and java-ize it, it > looks like it > > would bury the current machine we are using. > > > > Last question, does WAS start more instances when it needs to > > them to handle > > more requests like the HTTP server does? What about the new > > Apache server, > > does it start more jobs to handle more requests? > > > > Thanks! > > > > Brad > > > > +--- > > | This is the JAVA/400 Mailing List! > > | To submit a new message, send your mail to JAVA400-L@midrange.com. > > | To subscribe to this list send email to > JAVA400-L-SUB@midrange.com. > > | To unsubscribe from this list send email to > > JAVA400-L-UNSUB@midrange.com. > > | Questions should be directed to the list owner: joe@zappie.net > > +--- > > > > +--- > | This is the JAVA/400 Mailing List! > | To submit a new message, send your mail to JAVA400-L@midrange.com. > | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. > | To unsubscribe from this list send email to > JAVA400-L-UNSUB@midrange.com. > | Questions should be directed to the list owner: joe@zappie.net > +--- > +--- | This is the JAVA/400 Mailing List! | To submit a new message, send your mail to JAVA400-L@midrange.com. | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner: joe@zappie.net +---
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.