It's also possible that the complexity of the HTML tables you are creating
is slowing the page loading. One method to test for this is to determine if
you get the same response time with a variety of browsers. Tables are
notorious for slowing loading of pages - especially with Netscape 4.x.
If you load your pages with different browsers and the load times vary, try
simplifying the HTML.. If load times are similar, then it may go back to
processing of the pages. In particular, watch out for tables nested inside
tables.
Regarding Craig's suggestion below - one method to determine if it is JSP
compilation time is to see if you have page load times that are slow no
matter how many times you load the page. Since JSP compilation should only
be done the first time a page is hit, subsequent loads should be faster.
If the pages always load slowly no matter which browser you use and no
matter how many times you load the page, then it may go into what the
actual Java code is doing. But since you've indicated that the Action
classes are fast and the JSP pages are where the bottle neck is, I'd bet
anything that this isn't your problem.
Once good way to isolate the bottle neck is to write a series of
JUnit/Cactus tests and run them In-Container - processing times for the
Cactus tests will be listed out for all your tests so you can identify
which operatio
ns take the most time. The strutstestcase suite on sourceforge.net makes
cactus testing for Struts apps easy. Check it out at:
http://strutstestcase.sourceforge.net/
Best of luck,
Kevin
------
Kevin Bedell
author, Struts Kickstart - SAMS Publishing
"Craig R. McClanahan" <[EMAIL PROTECTED]> on 10/02/2002 12:21:53 PM
Please respond to "Struts Developers List" <[EMAIL PROTECTED]>
To: Struts Developers List <[EMAIL PROTECTED]>
cc: (bcc: Kevin Bedell/Systems/USHO/SunLife)
Subject: Re: Faster View Components...
On Wed, 2 Oct 2002, Jens Viebig wrote:
> Date: Wed, 2 Oct 2002 18:02:47 +0200
> From: Jens Viebig <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Faster View Components...
>
> Struts+JSP+Struts Taglibs are sometimes so terrible slow, i think even
perl
> would be faster...The Action Classes are as fast as i like it but
jsp-Stuff
> is terrible
> I have some complex pages with big tables (logic:iterate) and a lot of
> <bean:write> and <html:link> tags.
> Sometimes it takes longer than 10 seconds until the page starts loading
> Should i kick out the taglibs and do some scriptlet stuff ?
> Are there some faster alternatives to jsp to build the view ?
>
This is probably more a user-list question, but ...
Two things to be sure you are aware of:
* JSP pages (whether you use custom tags or not) are converted
into servlets and then compiled the first time you use them.
Be sure you are requesting the same page more than once to see
what response time your user will normally encounter. (If you
still see 10 seconds per page there, it is *much* more likely
to be caused by your database lookups than anything in the
view tier).
* The performance of JSP pages with lots of custom tags is *very*
dependent upon the quality of the code generated by the JSP page
compiler for your server. You don't say which one you are using,
but if it's Tomcat, check out the difference between running on
Tomcat 4.0.x and 4.1.x (which uses a completely rewritten page
compiler). Differences in the 600%-800% range (yes, that's six
to eight times faster) have been noticed in some cases, as a result
of the focus on optimization that the new compiler does.
For alternatives, you can use any view tier technology that can be
accessed via RequestDispatcher.forward() -- for example, some folks use
Velocity. But you'll obviously lose the functionality performed by the
JSP custom tags if you go this way.
> Greets
> Jens Viebig
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]
>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]
>
---------------------------------------------------------------------------
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure. If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---------------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
