I think it might be time to get a profiler on the app. 

-----Original Message-----
From: Charbel Abdul-Massih [mailto:[EMAIL PROTECTED] 
Sent: 23 May 2007 18:04
To: Struts Users Mailing List
Subject: RE: JSP pre-compile question

Again, Thanks for the suggestions...

I am running weblogic localhost, so there are no network delay issues...
I have the same page in JSF, and it does render right away...

I tried the below suggestions, but still having the same behavior...

Charbel

-----Original Message-----
From: Lance [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 23, 2007 11:56 AM
To: Struts Users Mailing List
Subject: Re: JSP pre-compile question

It sounds like it's a non-struts issue to me.

Try putting the following in the jsp after you draw the form <%
response.getWriter().flush(); %>

If it comes thru quickly there's something after you write the form that's
holding the page up.
You might need some println's with times or a debugger etc to see what's

going on.

 > it's as if the page is being streamed line by line, from top to bottom.
This depends on the app server but it could be byte by byte (via
response.getOutputStream())
 
Charbel Abdul-Massih wrote:
> Hi guys...Thanks for all your help so far, but to answer your 
> questions...
>
> The slowness in rendering the page is very obvious...it's as if the
page
> is being streamed line by line, from top to bottom...
>
> There are no images on the page...
>
> The page consists of 5 form fields...
>
> The request does not access any DB...
>
> The HTML outputted is only 17KB...
>
> I am running it locally on Weblogic 9.2 and Java 5...
>
> I doubt it's a pre-compile issue now because the slowness and 
> streaming-like rendering is experienced on every request, not just the 
> first...
>
> Any other ideas???
>
> Thanks,
> Charbel
>
>  
> -----Original Message-----
> From: Lance [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 23, 2007 11:22 AM
> To: Struts Users Mailing List
> Subject: Re: JSP pre-compile question
>
> This might also be because you are not specifying heights (and widths)

> for images.
> If you have any other static widths & heights (menu area, header area
> etc) you should specify them too.
>
> Lance.
>
> Al Sutton wrote:
>   
>> P.S.  If you're considering pre-compiling, the only thing you'll
loose
>>     
> is
>   
>> the lag for the first time the page is displayed, every time after
the
>>     
> first
>   
>> time you view a page almost all servlet engines will use the version
>>     
> which
>   
>> was compiled for the first page request.
>>
>> -----Original Message-----
>> From: Al Sutton [mailto:[EMAIL PROTECTED]
>> Sent: 23 May 2007 16:06
>> To: 'Struts Users Mailing List'
>> Subject: RE: JSP pre-compile question
>>
>> The short answer is no because this is how the browser receives the
>>     
> data
>   
>> about the page, and pretty much all browsers display the data as soon
>>     
> as
>   
>> they can after get it.
>>
>> There are things you can do to reduce the visibility of this to the
>>     
> user
>   
>> (smaller tables and div areas, smaller pages, etc.), but there isn't 
>> anything you can do about how the browser receives the data and
>>     
> chooses to
>   
>> render it.
>>
>> -----Original Message-----
>> From: Charbel Abdul-Massih [mailto:[EMAIL PROTECTED]
>> Sent: 23 May 2007 15:59
>> To: user@struts.apache.org
>> Subject: JSP pre-compile question
>>
>> Hi,
>>
>> I am evaluating Struts 2.0, and I'm using tiles pluging with it...
>>
>>  
>>
>> When my pages render in the browser, they seem to render top down,
>>     
> with a
>   
>> slight delay in rendering...meaning the top of the page renders
first,
>>     
> then
>   
>> the rest of the page renders gradually, until you see the full
>>     
> page...Is
>   
>> there a way to change this and have it render without the delay???
>>
>>  
>>
>> Thanks,
>> Charbel
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>   
>>     
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to