RE: WebLogic/Struts/JSP performance woes...
What JDBC driver lets you stream data over, before the resultset/rowset has finished retreving? Or is the data fast, just the rendering is slow? Oh no... We only start spitting the data out once it is all available. That takes between three and four seconds, and is a known and accepted lag. I do not think even Client/Server could do this nicely. Have you ever seen anyone else put out an application in any design that has 2000 rows? At my previous place of employment, we frequently retrieved more than 2000 rows (of XML data that was converted to HTML using XSLT). The data was ultimately displayed in a tree view so not all the data was initially visible, but it was all there, so we always had to retrieve all of it. We did do some work on implementing lazy loading so that only the visible data would be sent back to the browser, and only when users clicked a plus icon to expand a node would that node's data be retrieved and added to the tree. However, we got the code to the point where performance was acceptable without lazy loading. Now that I think about it, percieved performance might have been considered acceptable because we didn't use any tables to position it. Cheers... Dave Davide Bruzzone wrote: Lots of very ugly scriptlet code... :-) -Original Message- From: V. Cekvenich [mailto:vicc;users.sourceforge.net] Sent: Friday, November 01, 2002 2:32 PM To: [EMAIL PROTECTED] Subject: Re: WebLogic/Struts/JSP performance woes... 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... Snip -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: WebLogic/Struts/JSP performance woes...
Phil, No, but I'll look into it (I've never used JMeter before - If for no other reason, I'm curious about the tool). Thanks for the suggestion. Cheers... Dave -Original Message- From: Phil Steitz [mailto:phil;steitz.com] Sent: Saturday, November 02, 2002 10:35 AM To: Struts Users Mailing List 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: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: WebLogic/Struts/JSP performance woes...
To everyone that jumped in to help and provide suggestions: A big thank you! The list, as always, is fantastic, and proved to be more responsive and helpful than paid support. Kudos! BTW, I performed some tests on Friday based on the feedback that I got, and it looks like the problem was definately being caused by the HTML table. Cheers... Dave -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: WebLogic/Struts/JSP performance woes...
Daniel, 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. The query runs in under a second, and the data is available for use in about 3 - 4 seconds. 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. Interesting idea. In the end, depending on what the users say, we'll probably end up implementing a combination of some of the things that we've tried, and many of the things that have been suggested on this list. Cheers... Dave - Original Message - From: Phil Steitz [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] 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. -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: WebLogic/Struts/JSP performance woes...
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 [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] 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: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: WebLogic/Struts/JSP performance woes...
Not sure what you're code looks like, but you could try actually putting an out.println( //your HTML table row here) in your loop and see if you stop getting that blank page while your waiting for all the data to process. I'd go with the paging approach if your business users would allow it. - Original Message - From: Davide Bruzzone [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Sent: Friday, November 01, 2002 3:56 PM Subject: RE: WebLogic/Struts/JSP performance woes... I've tried both approaches... What's strange is that you'd expect every reload after the first one to take roughly the same amount of time (whether the pages are precompiled or not). However, this doesn't always seem to be the case which leads me to wonder what on earth is going on under the covers... Cheers... Dave -Original Message- From: Karr, David [mailto:david.karr;attws.com] Sent: Friday, November 01, 2002 1:49 PM To: Struts Users Mailing List Subject: RE: WebLogic/Struts/JSP performance woes... Is your page precompiled? Are you doing the timing test on your second display of the page? The first display of a non-precompiled JSP will take much longer, as it has to generate and compile the servlet class. -Original Message- From: Davide Bruzzone [mailto:Davide.Bruzzone;ngt.com] Sent: Friday, November 01, 2002 12:43 PM 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). -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: WebLogic/Struts/JSP performance woes...
Are you saying you could write a servlet that could stream out javascript? Interesting. Else search for the display tag on google. What JDBC driver lets you stream data over, before the resultset/rowset has finished retreving? Or is the data fast, just the rendering is slow? Like Craig says, you should use busines domain knowledge to improve the users experience, so they could drill down somehow. I do not think even Client/Server could do this nicely. Have you ever seen anyone else put out an application in any design that has 2000 rows? .V Davide Bruzzone wrote: Lots of very ugly scriptlet code... :-) -Original Message- From: V. Cekvenich [mailto:vicc;users.sourceforge.net] Sent: Friday, November 01, 2002 2:32 PM To: [EMAIL PROTECTED] Subject: Re: WebLogic/Struts/JSP performance woes... 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... Snip -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: WebLogic/Struts/JSP performance woes...
I do not think even Client/Server could do this nicely. Have you ever seen anyone else put out an application in any design that has 2000 rows? In a word, Yes. We had a client - system went live over 2 years ago using IIS on an Intranet as it happens. Client had 600 branches UK wide, with = 10 clients per branch (and in some cases many more than this) and wanted to see - on one page top (usually) 20 clients per branch with various metrics per client. No, they didn't want paging. No, they didn't want a smaller list (on this page). Yes - they wanted to see all records and then drill-down on the ones that interested them in a new browser window. We had to find a way to giving the customer what they had asked for or tell them it was not _technically_ feasible. The browser was known: IE5.5; it was always only ever accessed from a 100MBit LAN; the users were using powerful workstations. We used hints on the query to return top rows quickly - the metrics were calculated on data loading into the database - with incremental fetching and used fixed-width table to allow progresive fetching. Problem solved .. page was starting to render after about 3-4s and took about 40s to render fully - they could start viewing the data as soon as it started loading. Result: happy customer. What JDBC driver lets you stream data over, before the resultset/rowset has finished retreving? Or is the data fast, just the rendering is slow? I don't know if JDBC can do incremental fetching - even so retrieving 1,600 rows should not take that long if the query is sensibly written and has useful indexes available. H. -Original Message- From: news [mailto:news;main.gmane.org]On Behalf Of V. Cekvenich Sent: 02 November 2002 14:37 To: [EMAIL PROTECTED] Subject: Re: WebLogic/Struts/JSP performance woes... Are you saying you could write a servlet that could stream out javascript? Interesting. Else search for the display tag on google. What JDBC driver lets you stream data over, before the resultset/rowset has finished retreving? Or is the data fast, just the rendering is slow? Like Craig says, you should use busines domain knowledge to improve the users experience, so they could drill down somehow. I do not think even Client/Server could do this nicely. Have you ever seen anyone else put out an application in any design that has 2000 rows? V Davide Bruzzone wrote: Lots of very ugly scriptlet code... :-) -Original Message- From: V. Cekvenich [mailto:vicc;users.sourceforge.net] Sent: Friday, November 01, 2002 2:32 PM To: [EMAIL PROTECTED] Subject: Re: WebLogic/Struts/JSP performance woes... 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... Snip -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: WebLogic/Struts/JSP performance woes...
Yes, I use 6.1 sp2 at work, and I came across the exact same problem with an app just recently, and the problem was the html. The requirement for the app is to return all results on the same page (it currently returned 100 at a time), which means the possibility for rows and rows of data (the most I've returned in testing was over 4000). The problem with ours was the fact that the table and cell widths were all relative. In that case, IE would not render the table until all the data was returned so it could determine the width that all the table cells needed to be. The solution was to make the table a fixed-width by setting the table and cell widths to a certain number of pixels (instead of a percentage) and to set the table-layout style to fixed (see the CSS2 specs at www.w3c.org). The reason that setting table-layout to fixed makes it faster is that the browser will calculate the table using only the widths of the cells and not the data in the cells. So, it will render immediately. The problem you will have is if you cannot always predict the width of the data in the cell. If it is longer than the cell width, the cell will not adjust and the data will not wrap - it will get cut off (at least in IE). 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... Snip -- stu: www.stuology.net It just no longer is plain simple safe fun when it's the psycho chimp that has the ray gun Stuology -- A million monkeys can't be wrong -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
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: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
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: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: WebLogic/Struts/JSP performance woes...
I've not experienced this but 1760 rows seems like a lot to me. Will your users be able to view and process all this info? David From: Davide Bruzzone [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: WebLogic/Struts/JSP performance woes... Date: Fri, 1 Nov 2002 13:43:26 -0700 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: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org _ Unlimited Internet access for only $21.95/month. Try MSN! http://resourcecenter.msn.com/access/plans/2monthsfree.asp -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: WebLogic/Struts/JSP performance woes...
Also, are you using tables to display? You know table tr tdinserting data here.. Are you aware that these tables won't be displayed until all text required for this table have been downloaded? (This is true for IE and most others I'm sure) James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. - Albert Einstein (1879-1955) -Original Message- From: Karr, David [mailto:david.karr;attws.com] Sent: Friday, November 01, 2002 3:49 PM To: Struts Users Mailing List Subject: RE: WebLogic/Struts/JSP performance woes... Is your page precompiled? Are you doing the timing test on your second display of the page? The first display of a non-precompiled JSP will take much longer, as it has to generate and compile the servlet class. -Original Message- From: Davide Bruzzone [mailto:Davide.Bruzzone;ngt.com] Sent: Friday, November 01, 2002 12:43 PM 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). -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: WebLogic/Struts/JSP performance woes...
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: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: WebLogic/Struts/JSP performance woes...
Yes...
Again, what's strange is that during my extensive tests/experiments/hair
pulling sessions I've actually seen this type of code work (using tables) -
There's still a small lag between when the page clears and when the output
starts to appear, but output definately starts to appear before the server
is done:
for (int i = 0; i myCollection.size(); i++) {
out.print(/tr);
out.print(td);
out.print(myData);
out.print(/td);
out.print(/tr);
out.flush();
}
Although by that point, the page that I was using to perform the tests had
been tinkered with extensively, so not all the table tags may have been
there which might have allowed the browser to render the output sooner. What
other tags would you suggest? divs?
Cheers...
Dave
-Original Message-
From: James Mitchell [mailto:jmitchtx;telocity.com]
Sent: Friday, November 01, 2002 1:55 PM
To: Struts Users Mailing List
Subject: RE: WebLogic/Struts/JSP performance woes...
Also, are you using tables to display?
You know
table
tr
tdinserting data here..
Are you aware that these tables won't be displayed until all text required
for this table have been downloaded? (This is true for IE and most others
I'm sure)
James Mitchell
Software Engineer/Struts Evangelist
http://www.open-tools.org
Only two things are infinite, the universe and human stupidity, and I'm not
sure about the former.
- Albert Einstein (1879-1955)
-Original Message-
From: Karr, David [mailto:david.karr;attws.com]
Sent: Friday, November 01, 2002 3:49 PM
To: Struts Users Mailing List
Subject: RE: WebLogic/Struts/JSP performance woes...
Is your page precompiled? Are you doing the timing test on your
second display of the page? The first display of a
non-precompiled JSP will take much longer, as it has to generate
and compile the servlet class.
-Original Message-
From: Davide Bruzzone [mailto:Davide.Bruzzone;ngt.com]
Sent: Friday, November 01, 2002 12:43 PM
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).
--
To unsubscribe, e-mail:
mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:struts-user-help;jakarta.apache.org
--
To unsubscribe, e-mail:
mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:struts-user-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: WebLogic/Struts/JSP performance woes...
You need to break it up into separate tables, in chunks, if you want portions to
display incrementally, rather than the whole table all at once. The reason the
browser waits is beacause if it started rendering the table, but some row down
in the ~1000 area had an especially wide td cell, then it would have to push
all it's neighbors over and re-render the table. So, browsers wait until they
see a closing /table tag. It doesn't have much to do with any server-side
technology.
If you just *have* to show something to the user while they wait for the whole
table, you could try making a separate, complete header table. The browser
would display it first, then chug away building the table for the hundreds of
rows.
Good luck,
NAT
-Original Message-
From: Davide Bruzzone [mailto:Davide.Bruzzone;ngt.com]
Sent: Friday, November 01, 2002 1:03 PM
To: 'Struts Users Mailing List'
Subject: RE: WebLogic/Struts/JSP performance woes...
Yes...
Again, what's strange is that during my extensive tests/experiments/hair
pulling sessions I've actually seen this type of code work (using tables) -
There's still a small lag between when the page clears and when the output
starts to appear, but output definately starts to appear before the server
is done:
for (int i = 0; i myCollection.size(); i++) {
out.print(/tr);
out.print(td);
out.print(myData);
out.print(/td);
out.print(/tr);
out.flush();
}
Although by that point, the page that I was using to perform the tests had
been tinkered with extensively, so not all the table tags may have been
there which might have allowed the browser to render the output sooner. What
other tags would you suggest? divs?
Cheers...
Dave
-Original Message-
From: James Mitchell [mailto:jmitchtx;telocity.com]
Sent: Friday, November 01, 2002 1:55 PM
To: Struts Users Mailing List
Subject: RE: WebLogic/Struts/JSP performance woes...
Also, are you using tables to display?
You know
table
tr
tdinserting data here..
Are you aware that these tables won't be displayed until all text required
for this table have been downloaded? (This is true for IE and most others
I'm sure)
James Mitchell
Software Engineer/Struts Evangelist
http://www.open-tools.org
Only two things are infinite, the universe and human stupidity, and I'm not
sure about the former.
- Albert Einstein (1879-1955)
-Original Message-
From: Karr, David [mailto:david.karr;attws.com]
Sent: Friday, November 01, 2002 3:49 PM
To: Struts Users Mailing List
Subject: RE: WebLogic/Struts/JSP performance woes...
Is your page precompiled? Are you doing the timing test on your
second display of the page? The first display of a
non-precompiled JSP will take much longer, as it has to generate
and compile the servlet class.
-Original Message-
From: Davide Bruzzone [mailto:Davide.Bruzzone;ngt.com]
Sent: Friday, November 01, 2002 12:43 PM
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).
--
To unsubscribe, e-mail:
mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:struts-user-help;jakarta.apache.org
--
To unsubscribe, e-mail:
mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:struts-user-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: WebLogic/Struts/JSP performance woes...
Hi Davide,
I'm pretty sure what you're seeing is browser-related, if you are flushing
the output periodically from the server: Nat and James have already stated,
tables will _likely_ not render until the width of all columns are known ...
sometimes the table _will_ progressively render and then shift about as
wider columns are required in later rows. (You can sometimes check this by
waiting a short while so the table has partly downloading and pressing
stop which usually causes what has been downloaded to display). The actual
behaviour tends to be browser-specific and from our tests with IE (5.01SP2)
also seemed inconsistent. This is how we got a very satisfatory result:
I'm not sure if this is IE-only behaviour so forgive me if this does not
apply to other browsers - but this may serve as a starting point for
investigation. CSS2 which I presume is Cascade Style Sheets V2 supports the
concept of fixed-width tables, from:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie50/html
/cheatsheet.asp (Fixed Width Tables section):
HTML tables are normally relatively slow to appear, since browsers
calculate the size of each cell in the table before beginning to draw it.
When you set the CSS2 table-layout property to FIXED, the browser uses the
column-width and row-height information in the first row of the table to lay
out the table immediately. Fixed tables render progressively, resulting in a
significant speed improvement.
We had to use this in an Intranet app that was producing huge tables, i.e.
sometimes 30,000 rows. And, yes, they did ...really, really want to see
all the data... (accountants). Utilising fixed-width tables produced a
_significant_ increase in *perceived* speed of page download. The following
excerpt was taken from:
http://msdn.microsoft.com/workshop/author/tables/tables_overview.asp#layout
The following example shows the use of the Cascading Style Sheets (CSS)
attribute, table-layout, to fix the table layout, resulting in faster
rendering of the table. Note that the widths need not be set on the TABLE
and COL objects. When the width is not specified, the browser looks to the
contents of the first row's cells to fix the column widths and,
consequently, the table width.
TABLE STYLE=table-layout:fixed WIDTH=600
COL WIDTH=100COL WIDTH=300COL WIDTH=200
TR HEIGHT=20
TD.../TDTD.../TDTD.../TD
/TR
:
/TABLE
The performance gains are significant, especially for large tables. Because
the browser does not need to parse through the table once simply to lay it
out, the table rows can start to render immediately.
HTH,
Hue.
-Original Message-
From: Davide Bruzzone [mailto:Davide.Bruzzone;ngt.com]
Sent: 01 November 2002 21:03
To: 'Struts Users Mailing List'
Subject: RE: WebLogic/Struts/JSP performance woes...
Yes...
Again, what's strange is that during my extensive tests/experiments/hair
pulling sessions I've actually seen this type of code work (using tables) -
There's still a small lag between when the page clears and when the output
starts to appear, but output definately starts to appear before the server
is done:
for (int i = 0; i myCollection.size(); i++) {
out.print(/tr);
out.print(td);
out.print(myData);
out.print(/td);
out.print(/tr);
out.flush();
}
Although by that point, the page that I was using to perform the tests had
been tinkered with extensively, so not all the table tags may have been
there which might have allowed the browser to render the output sooner. What
other tags would you suggest? divs?
Cheers...
Dave
-Original Message-
From: James Mitchell [mailto:jmitchtx;telocity.com]
Sent: Friday, November 01, 2002 1:55 PM
To: Struts Users Mailing List
Subject: RE: WebLogic/Struts/JSP performance woes...
Also, are you using tables to display?
You know
table
tr
tdinserting data here..
Are you aware that these tables won't be displayed until all text required
for this table have been downloaded? (This is true for IE and most others
I'm sure)
James Mitchell
Software Engineer/Struts Evangelist
http://www.open-tools.org
Only two things are infinite, the universe and human stupidity, and I'm not
sure about the former.
- Albert Einstein (1879-1955)
-Original Message-
From: Karr, David [mailto:david.karr;attws.com]
Sent: Friday, November 01, 2002 3:49 PM
To: Struts Users Mailing List
Subject: RE: WebLogic/Struts/JSP performance woes...
Is your page precompiled? Are you doing the timing test on your
second display of the page? The first display of a
non-precompiled JSP will take much longer, as it has to generate
and compile the servlet class.
-Original Message-
From: Davide Bruzzone [mailto:Davide.Bruzzone;ngt.com]
Sent: Friday, November 01, 2002 12:43 PM
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
Re: WebLogic/Struts/JSP performance woes...
On Fri, 1 Nov 2002, Davide Bruzzone wrote: Date: Fri, 1 Nov 2002 13:43:26 -0700 From: Davide Bruzzone [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] 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: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: WebLogic/Struts/JSP performance woes...
Lots of very ugly scriptlet code... :-) -Original Message- From: V. Cekvenich [mailto:vicc;users.sourceforge.net] Sent: Friday, November 01, 2002 2:32 PM To: [EMAIL PROTECTED] Subject: Re: WebLogic/Struts/JSP performance woes... 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... Snip -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: WebLogic/Struts/JSP performance woes...
Actually, one of the options that I considered was using paging tags, and displaying the data say 20 or 50 records at a time. However, the users may have a need to see all the data at once in a data storm situation. There may not be as many rows, but its not impossible, so the application has to be able to handle it gracefully. Cheers... Dave -Original Message- From: David Graham [mailto:dgraham1980;hotmail.com] Sent: Friday, November 01, 2002 1:49 PM To: [EMAIL PROTECTED] Subject: Re: WebLogic/Struts/JSP performance woes... I've not experienced this but 1760 rows seems like a lot to me. Will your users be able to view and process all this info? David From: Davide Bruzzone [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: WebLogic/Struts/JSP performance woes... Date: Fri, 1 Nov 2002 13:43:26 -0700 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: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org _ Unlimited Internet access for only $21.95/month. Try MSN! http
RE: WebLogic/Struts/JSP performance woes...
I've tried both approaches... What's strange is that you'd expect every reload after the first one to take roughly the same amount of time (whether the pages are precompiled or not). However, this doesn't always seem to be the case which leads me to wonder what on earth is going on under the covers... Cheers... Dave -Original Message- From: Karr, David [mailto:david.karr;attws.com] Sent: Friday, November 01, 2002 1:49 PM To: Struts Users Mailing List Subject: RE: WebLogic/Struts/JSP performance woes... Is your page precompiled? Are you doing the timing test on your second display of the page? The first display of a non-precompiled JSP will take much longer, as it has to generate and compile the servlet class. -Original Message- From: Davide Bruzzone [mailto:Davide.Bruzzone;ngt.com] Sent: Friday, November 01, 2002 12:43 PM 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). -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
