You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Davide Bruzzone <Da...@ngt.com> on 2002/11/01 21:43:26 UTC
WebLogic/Struts/JSP performance woes...
Greetings all...
I'd like to try to find out if anyone else out there is using WebLogic
(We're using version 6.1 SP2) with Struts and/or just JSPs that might have
some performance tips that they might be able to share...
Here's what's happening:
I have a page that, for test purposes, is generating a 1760 row table (Not a
gigantic table by any stretch of the imagination). Although I don't expect
our data sets to be this big all the time, I need to make the application
responsive (i.e. If it starts displaying rows immediately - while its still
spitting out other rows - that's fine. What's unacceptable is if the
application takes a while to do whatever its doing, and doesn't generate any
output until its done, leaving the user with a blank page while they wait).
I started out using Struts on the page, and found that the performance
wasn't good enough. So I converted the portion of the page that loops
through the contents of a collection of objects and creates the output to a
scriptlet - the reasoning being that I could perform the relatively simple
processing more directly/with less overhead if I just did it directly).
Performance improved somewhat, but I'm still faced with the problem related
to the fact that I don't get any output immediately (regardless of how long
the whole page takes to generate).
I've tried what seems like an endless combination of alternatives, with
mixed results (And that's one of the problems... I seem to get wildly
different results even with exactly the same code!). Here's what I've tried:
- I've set the buffer page directive to "none"
- I've tried to remove any Struts tags from the page in different
combinations (with mixed results)
- Since the page originally used templates (We're using Struts 1.0.2), I
tried to remove those, and have just one page (Again, with mixed results)
- I've added out.flush() at the end of each loop iteration (The intention
being that the server should spit out the row as soon as its done with it).
I've also added logging to the JSP to see how long each step is taking, and
as I've said, I keep getting mixed results (Both when I use our real data,
and, say, a loop that prints out "Hello" one million times). Sometimes rows
seem to start to display before the server is done, and sometimes they
don't. Sometimes the loop takes a long time to process, and sometimes it
doesn't... Here's some sample log output for the loop:
%%%%%%%%%%%: Done with initialization... Starting loop... Fri Nov 01
13:17:49 MST 2002
1557934 [11-01 13:17:49:512] INFO [ExecuteThread: '11' for queue:
'default'] (__surveillancepanel.java:332) - #########
###########: Flushed... 0
1559871 [11-01 13:17:51:449] INFO [ExecuteThread: '11' for queue:
'default'] (__surveillancepanel.java:332) - #########
###########: Flushed... 500
1561934 [11-01 13:17:53:512] INFO [ExecuteThread: '11' for queue:
'default'] (__surveillancepanel.java:332) - #########
###########: Flushed... 1000
1564527 [11-01 13:17:56:105] INFO [ExecuteThread: '11' for queue:
'default'] (__surveillancepanel.java:332) - #########
###########: Flushed... 1500
1566074 [11-01 13:17:57:652] INFO [ExecuteThread: '11' for queue:
'default'] (__surveillancepanel.java:336) - %%%%%%%%%
%%%%%%%%%%%: Done with loop... Fri Nov 01 13:17:57 MST 2002
So I know that the server is able to process 500 rows of output in 63
milliseconds (See the difference between row 0 and row 500). However, I'm
still getting this lag time before I start to see any output.
If I'm doing something wrong with regard to Struts, and can get the rows to
display as soon as they're available, I'm perfectly willing to use Struts
(or whatever other approach works). Does anyone have any experience in this
area? Any help would be greatly appreciated...
Cheers...
Davide Bruzzone
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: WebLogic/Struts/JSP performance woes...
Posted by Daniel Jaffa <ja...@courtinnovation.org>.
Have you tried looking at the Query that you using. 1760 rows from a
database may some time to transfer and query up. You can sometimes shave
seconds from a query by just changing the order of the FROM clause and WHERE
conditions.
Since you said that only sometimes that the users need to see all the rows,
why do you not implement a paging by default. Then have an option to see
all rows.
----- Original Message -----
From: "Phil Steitz" <ph...@steitz.com>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Saturday, November 02, 2002 12:34 PM
Subject: Re: WebLogic/Struts/JSP performance woes...
> David,
>
> Have you considered running some tests with Jmeter or some other testing
> tool that can tell you exactly how long it takes to deliver the HTML?
> This would enable you to determine whether the problem is on the server
> side or in the browser rendering.
>
> Regards,
>
> Phil
>
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: WebLogic/Struts/JSP performance woes...
Posted by Phil Steitz <ph...@steitz.com>.
David,
Have you considered running some tests with Jmeter or some other testing
tool that can tell you exactly how long it takes to deliver the HTML?
This would enable you to determine whether the problem is on the server
side or in the browser rendering.
Regards,
Phil
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: WebLogic/Struts/JSP performance woes...
Posted by "V. Cekvenich" <vi...@users.sourceforge.net>.
How would you solve this w/o Struts?
.V
Davide Bruzzone wrote:
> Greetings all...
>
> I'd like to try to find out if anyone else out there is using WebLogic
> (We're using version 6.1 SP2) with Struts and/or just JSPs that might have
> some performance tips that they might be able to share...
>
> Here's what's happening:
>
> I have a page that, for test purposes, is generating a 1760 row table (Not a
> gigantic table by any stretch of the imagination). Although I don't expect
> our data sets to be this big all the time, I need to make the application
> responsive (i.e. If it starts displaying rows immediately - while its still
> spitting out other rows - that's fine. What's unacceptable is if the
> application takes a while to do whatever its doing, and doesn't generate any
> output until its done, leaving the user with a blank page while they wait).
>
> I started out using Struts on the page, and found that the performance
> wasn't good enough. So I converted the portion of the page that loops
> through the contents of a collection of objects and creates the output to a
> scriptlet - the reasoning being that I could perform the relatively simple
> processing more directly/with less overhead if I just did it directly).
> Performance improved somewhat, but I'm still faced with the problem related
> to the fact that I don't get any output immediately (regardless of how long
> the whole page takes to generate).
>
> I've tried what seems like an endless combination of alternatives, with
> mixed results (And that's one of the problems... I seem to get wildly
> different results even with exactly the same code!). Here's what I've tried:
>
> - I've set the buffer page directive to "none"
> - I've tried to remove any Struts tags from the page in different
> combinations (with mixed results)
> - Since the page originally used templates (We're using Struts 1.0.2), I
> tried to remove those, and have just one page (Again, with mixed results)
> - I've added out.flush() at the end of each loop iteration (The intention
> being that the server should spit out the row as soon as its done with it).
>
> I've also added logging to the JSP to see how long each step is taking, and
> as I've said, I keep getting mixed results (Both when I use our real data,
> and, say, a loop that prints out "Hello" one million times). Sometimes rows
> seem to start to display before the server is done, and sometimes they
> don't. Sometimes the loop takes a long time to process, and sometimes it
> doesn't... Here's some sample log output for the loop:
>
> %%%%%%%%%%%: Done with initialization... Starting loop... Fri Nov 01
> 13:17:49 MST 2002
> 1557934 [11-01 13:17:49:512] INFO [ExecuteThread: '11' for queue:
> 'default'] (__surveillancepanel.java:332) - #########
> ###########: Flushed... 0
> 1559871 [11-01 13:17:51:449] INFO [ExecuteThread: '11' for queue:
> 'default'] (__surveillancepanel.java:332) - #########
> ###########: Flushed... 500
> 1561934 [11-01 13:17:53:512] INFO [ExecuteThread: '11' for queue:
> 'default'] (__surveillancepanel.java:332) - #########
> ###########: Flushed... 1000
> 1564527 [11-01 13:17:56:105] INFO [ExecuteThread: '11' for queue:
> 'default'] (__surveillancepanel.java:332) - #########
> ###########: Flushed... 1500
> 1566074 [11-01 13:17:57:652] INFO [ExecuteThread: '11' for queue:
> 'default'] (__surveillancepanel.java:336) - %%%%%%%%%
> %%%%%%%%%%%: Done with loop... Fri Nov 01 13:17:57 MST 2002
>
> So I know that the server is able to process 500 rows of output in 63
> milliseconds (See the difference between row 0 and row 500). However, I'm
> still getting this lag time before I start to see any output.
>
> If I'm doing something wrong with regard to Struts, and can get the rows to
> display as soon as they're available, I'm perfectly willing to use Struts
> (or whatever other approach works). Does anyone have any experience in this
> area? Any help would be greatly appreciated...
>
> Cheers...
>
> Davide Bruzzone
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: WebLogic/Struts/JSP performance woes...
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 1 Nov 2002, Davide Bruzzone wrote:
> Date: Fri, 1 Nov 2002 13:43:26 -0700
> From: Davide Bruzzone <Da...@ngt.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: "'struts-user@jakarta.apache.org'" <st...@jakarta.apache.org>
> Subject: WebLogic/Struts/JSP performance woes...
>
> Greetings all...
>
> I'd like to try to find out if anyone else out there is using WebLogic
> (We're using version 6.1 SP2) with Struts and/or just JSPs that might have
> some performance tips that they might be able to share...
>
> Here's what's happening:
>
> I have a page that, for test purposes, is generating a 1760 row table (Not a
> gigantic table by any stretch of the imagination). Although I don't expect
> our data sets to be this big all the time, I need to make the application
> responsive (i.e. If it starts displaying rows immediately - while its still
> spitting out other rows - that's fine. What's unacceptable is if the
> application takes a while to do whatever its doing, and doesn't generate any
> output until its done, leaving the user with a blank page while they wait).
>
There are at least a couple of things going on here to watch out for
(neither of which Struts can really help you much with):
* How fast does your database actually retrieve the data? Because
you found that switching to scriptlets didn't help a lot, I suspect
that this is going to be the ultimate limit to how fast your page
can be rendered (although you can certainly improve the "perceived"
response time by beginning visual rendering before the response
has been completed.
* What browser are you testing with? If it's Netscape 4.x, you're going
to be in a world of hurt -- besides being very slow in the first place,
Netscape 4.x won't start rendering an HTML <table> until the </table>
element has been received. Try a newer browser, or divide up your
huge table into separate shorter tables (say, every 50 rows or so).
My stronger advice, though, is that a 1760 row table is not particularly
usable even if it rendered instantly. I'd suggest looking at strategies
that let the user refine what they are searching for more carefully,
and/or set things up to scroll through multiple short result pages (like a
search engine does).
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>