Re: Speeding Up HTML Parse???
a) Read the speed tracer output, if the time is spent with the redirect or loading the actual markup it will tell you. b) HTML rendering in the browser is influenced by the markup and ajax. Read the speed tracer output and it will tell you where the time is spent. It's most likely not wicket that costs the initial 30 second delay but some resource taking long to load, an AJAX component doing its magic ... But that's all client(browser)-side stuff.
RE: Speeding Up HTML Parse???
Thanks Russell. This is good information. I am going to evaluate the server side activity first and then will look into any inefficiencies on the client. J.D. -Original Message- From: Russell Morrisey [mailto:russell.morri...@missionse.com] Sent: Thursday, February 25, 2010 11:39 AM To: users@wicket.apache.org Subject: RE: Speeding Up HTML Parse??? Before spending a lot of time trying to debug client-side performance, be sure that the problem is on the client side, and not the server. A lot of performance problems I see on my project arise from user code on the server side which takes a long time to run (such as redundant or inefficient database hits). If you do find that the problem is client-side, a couple of ideas of things to look for: -Excessive/redundant javascript. Externalize scripts as much as possible, using header contribution, instead of pushing all of the logic out in an ajax request. -Heavy javascript widgets (I think you mentioned using YUI controls in an earlier message? Maybe they are taking a long time to run or too much memory?) -User agent memory leaks or pseudo leaks which cause performance to degrade over time (especially in IE) MSDN actually has a fairly useful article on IE memory leaks: http://msdn.microsoft.com/en-us/library/bb250448%28VS.85%29.aspx Don't try to fix until you've verified the source of the performance hit. RUSSELL E. MORRISEY Programmer Analyst Professional Mission Solutions Engineering, LLC | russell.morri...@missionse.com | www.missionse.com -Original Message- From: Jochen Mader [mailto:pflanzenmoer...@gmail.com] Sent: Thursday, February 25, 2010 4:48 AM To: users@wicket.apache.org Subject: Re: Speeding Up HTML Parse??? a) Read the speed tracer output, if the time is spent with the redirect or loading the actual markup it will tell you. b) HTML rendering in the browser is influenced by the markup and ajax. Read the speed tracer output and it will tell you where the time is spent. It's most likely not wicket that costs the initial 30 second delay but some resource taking long to load, an AJAX component doing its magic ... But that's all client(browser)-side stuff. This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind MSE to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Speeding Up HTML Parse???
Before spending a lot of time trying to debug client-side performance, be sure that the problem is on the client side, and not the server. A lot of performance problems I see on my project arise from user code on the server side which takes a long time to run (such as redundant or inefficient database hits). If you do find that the problem is client-side, a couple of ideas of things to look for: -Excessive/redundant javascript. Externalize scripts as much as possible, using header contribution, instead of pushing all of the logic out in an ajax request. -Heavy javascript widgets (I think you mentioned using YUI controls in an earlier message? Maybe they are taking a long time to run or too much memory?) -User agent memory leaks or pseudo leaks which cause performance to degrade over time (especially in IE) MSDN actually has a fairly useful article on IE memory leaks: http://msdn.microsoft.com/en-us/library/bb250448%28VS.85%29.aspx Don't try to fix until you've verified the source of the performance hit. RUSSELL E. MORRISEY Programmer Analyst Professional Mission Solutions Engineering, LLC | russell.morri...@missionse.com | www.missionse.com -Original Message- From: Jochen Mader [mailto:pflanzenmoer...@gmail.com] Sent: Thursday, February 25, 2010 4:48 AM To: users@wicket.apache.org Subject: Re: Speeding Up HTML Parse??? a) Read the speed tracer output, if the time is spent with the redirect or loading the actual markup it will tell you. b) HTML rendering in the browser is influenced by the markup and ajax. Read the speed tracer output and it will tell you where the time is spent. It's most likely not wicket that costs the initial 30 second delay but some resource taking long to load, an AJAX component doing its magic ... But that's all client(browser)-side stuff. This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind MSE to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Speeding Up HTML Parse???
I'm profiling our Wicket Application using Google's Speed Tracer Plugin (nice plugin). The profiling tool is showing most of the time spent in two areas, 1) Parsing HTMlL 2) Javascript Valuation (mostly with YUI). What are some of the best practices around developing code that minimizes the impact of parsing HTML in Wicket? We haven't had a lot of time to optimize our code and now are starting to look at that aspect of our application. Thanks, J.D.
Re: Speeding Up HTML Parse???
On Wed, Feb 24, 2010 at 1:26 PM, Corbin, James jcor...@iqnavigator.com wrote: I'm profiling our Wicket Application using Google's Speed Tracer Plugin (nice plugin). The profiling tool is showing most of the time spent in two areas, 1) Parsing HTMlL this measures the browser's speed not wickets besides, where does most of the time browserside should go? shouldnt it be parsing html? thats what browsers do... -igor 2) Javascript Valuation (mostly with YUI). What are some of the best practices around developing code that minimizes the impact of parsing HTML in Wicket? We haven't had a lot of time to optimize our code and now are starting to look at that aspect of our application. Thanks, J.D. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Speeding Up HTML Parse???
Yes Igor, I understand that, but some of our display pages initially take a very long time to initially render. For example, we have editors that take upwards of 30 seconds to render initially. Subsequent renders are obviously quicker. I guess what I am trying to say, are there any best practices for reducing the initial load time of pages. -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Wednesday, February 24, 2010 2:58 PM To: users@wicket.apache.org Subject: Re: Speeding Up HTML Parse??? On Wed, Feb 24, 2010 at 1:26 PM, Corbin, James jcor...@iqnavigator.com wrote: I'm profiling our Wicket Application using Google's Speed Tracer Plugin (nice plugin). The profiling tool is showing most of the time spent in two areas, 1) Parsing HTMlL this measures the browser's speed not wickets besides, where does most of the time browserside should go? shouldnt it be parsing html? thats what browsers do... -igor 2) Javascript Valuation (mostly with YUI). What are some of the best practices around developing code that minimizes the impact of parsing HTML in Wicket? We haven't had a lot of time to optimize our code and now are starting to look at that aspect of our application. Thanks, J.D. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Speeding Up HTML Parse???
wicket buffers your output, which may affect the time it takes the browser to get the initial markup. eg the markup is not streamed as wicket is rendering but is sent in one large chunk once the render on serverside is complete. you can change the render strategy to ONE_PASS_RENDER but then you will lose features like redirect-after-post, the ability to use RestartResponseException mid-render, etc. -igor On Wed, Feb 24, 2010 at 2:14 PM, Corbin, James jcor...@iqnavigator.com wrote: Yes Igor, I understand that, but some of our display pages initially take a very long time to initially render. For example, we have editors that take upwards of 30 seconds to render initially. Subsequent renders are obviously quicker. I guess what I am trying to say, are there any best practices for reducing the initial load time of pages. -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Wednesday, February 24, 2010 2:58 PM To: users@wicket.apache.org Subject: Re: Speeding Up HTML Parse??? On Wed, Feb 24, 2010 at 1:26 PM, Corbin, James jcor...@iqnavigator.com wrote: I'm profiling our Wicket Application using Google's Speed Tracer Plugin (nice plugin). The profiling tool is showing most of the time spent in two areas, 1) Parsing HTMlL this measures the browser's speed not wickets besides, where does most of the time browserside should go? shouldnt it be parsing html? thats what browsers do... -igor 2) Javascript Valuation (mostly with YUI). What are some of the best practices around developing code that minimizes the impact of parsing HTML in Wicket? We haven't had a lot of time to optimize our code and now are starting to look at that aspect of our application. Thanks, J.D. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Speeding Up HTML Parse???
On Wed, Feb 24, 2010 at 2:14 PM, Corbin, James jcor...@iqnavigator.com wrote: For example, we have editors that take upwards of 30 seconds to render initially. what is the processing time of the entire request on the serverside? is it 30 seconds??? -igor Subsequent renders are obviously quicker. I guess what I am trying to say, are there any best practices for reducing the initial load time of pages. -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Wednesday, February 24, 2010 2:58 PM To: users@wicket.apache.org Subject: Re: Speeding Up HTML Parse??? On Wed, Feb 24, 2010 at 1:26 PM, Corbin, James jcor...@iqnavigator.com wrote: I'm profiling our Wicket Application using Google's Speed Tracer Plugin (nice plugin). The profiling tool is showing most of the time spent in two areas, 1) Parsing HTMlL this measures the browser's speed not wickets besides, where does most of the time browserside should go? shouldnt it be parsing html? thats what browsers do... -igor 2) Javascript Valuation (mostly with YUI). What are some of the best practices around developing code that minimizes the impact of parsing HTML in Wicket? We haven't had a lot of time to optimize our code and now are starting to look at that aspect of our application. Thanks, J.D. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
