|
For the moment we have a response between 1-3 minutes! Now, when nobody's at the office anymore, I have a response between 20 and 45 seconds. Where can we find more detailed info about 1) how to implement WebFacing trace-info 2) AS400 side of WebFacing (i.e. libraries used by VT) -----Oorspronkelijk bericht----- Van: java400-l-admin@midrange.com [mailto:java400-l-admin@midrange.com] Namens Jim Mason Verzonden: dinsdag 15 januari 2002 20:50 Aan: java400-l@midrange.com Onderwerp: RE: WebFacing performance considerations update Hi. There are a bunch of items to check for normal performance on iSeries for Java and regular application workload BUT the primary impact on initial webfacing response times is usually class loading. Once classes ARE loaded, we've had reasonably good web response times ( on the order of 2 seconds ) for screens. There are tools in WebSphere for performance tracing as well as the IBM Distributed Debug tool as well as JDK 1.3 support for standard JPDA. In addition, check the webfacing server jobs and the invoked 5250 job for performance and resource bottlenecks. I had one customer that tried to put webfacing apps on a production AS/400 also running a full domino server AND only left 166 mb pool for WebSphere Advanced to run in !!! Yes, response time was terrible ..... Jim Mason --- Patrick Goovaerts <pgoovaerts@pandora.be> wrote: > Starting Implementing WebFacing was as follows: > > 1) First problem was converting the application in > WebFacing. No > conversionreport was generated. > ==> after loading SP4, all seemed ok. At first I > didn't find it on the > IBM site. I was switching from 'Support' to 'Info' > page over and over. > Then I tried the 'DOWNLOAD' option... Bingo... > > 2) Second problem was loading application into > VAJAVA Test Environment. > It couldn't find the Servlets. > ==> It appears I had to add the webpath to > jsp/servlets manually into > VAJAVA TE! This means that for every app to test, > you have to change > this path in WTE! I found this sollution in one of > the newsgroups. > > 3) Next, I got a response that the WF-Level was not > correct > ==> I installed the PTF's (should have done it > first, it's in the > documentation) > > 4) Finally, there were no errors shown but also no application > screens. ==> I had to add the Virtual Devices to an > Interactive Subsystem, but > this was not in any doc I have! I found out about > this VT's because I > was looking at the joblogs. > ==> It seems one also have to add the libraries one > by one to the jobd > linked to the usrprf. We used to work with a > generic value but this > seems to fail? > > What's left now? > - What slows down the application when called in > browser? How to detect > this? > - Where to find more info about AS400-side of > WebFacing? (i.e. which > librarylist is used) > - What are 'general' sysspec to use WebFacing? > we have only one system (720) which is used by our employees for > Daily activity. This system also has WAS3.5.2 running and > a couple of Notes > Mail servers. Which leads us to: This will be the > reason that the > applications are so slowly. But how can we be sure? > > I don't expect the panels coming up as fast as green > screens but this is > really too slow now. At the current speed, the > users will think they > haven't clicked a button correctly and do it again > and again... > > Patrick > > -----Oorspronkelijk bericht----- > Van: java400-l-admin@midrange.com > [mailto:java400-l-admin@midrange.com] > Namens Alex A Moore > Verzonden: dinsdag 15 januari 2002 19:08 > Aan: java400-l@midrange.com > Onderwerp: RE: WebFacing application EXTREEMLY slow > > > So, what was the solution that made your application > work? I don't know > enough about performance yet. My first load of a > panel is also > extremely slow - about a minute. I'm assuming this > is because of the > reason you mentioned. Subsequent use of the same > panel is noticeably > faster, but no where close to green screen response > times. > > Alex > > > OK, now that I managed to get my first application > converted, added to > > > WAS3.5.2 and started from a browser.... > > > > I have to wait 1-3 minutes before a page is loaded > in by browser. > > > > Is this normal? > > > > My thought was that this could be normal the first > load only (because > > the JSP's needed to be compiled)... > > > _______________________________________________ > This is the Java Programming on and around the > iSeries / AS400 > (JAVA400-L) mailing list > To post a message email: JAVA400-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: > http://lists.midrange.com/cgi-bin/listinfo/java400-l > or email: JAVA400-L-request@midrange.com > Before posting, please take a moment to review the > archives > at http://archive.midrange.com/java400-l. > > > _______________________________________________ > This is the Java Programming on and around the > iSeries / AS400 (JAVA400-L) mailing list > To post a message email: JAVA400-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: > http://lists.midrange.com/cgi-bin/listinfo/java400-l > or email: JAVA400-L-request@midrange.com > Before posting, please take a moment to review the > archives > at http://archive.midrange.com/java400-l. > __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ _______________________________________________ This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) mailing list To post a message email: JAVA400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l or email: JAVA400-L-request@midrange.com 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.