You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by "Aaron J. Garcia" <ag...@rentec.com> on 2015/09/13 23:49:27 UTC
Performance Degredation for Adding Components in Wicket 7.0.0 vs. Wicket 6.20.0
Hello,
I'm hoping someone here can help me. My organization uses Wicket as the
framework for a fairly large internal web application.
We have a page that renders a hierarchal data table. It's implemented with
a RepeatingView for the table rows, and various WebMarkupContainers for the
columns (each column's component for one row gets attached to a new
WebMarkupContainer(rv.newChildId()) container). Anyway, the table has about
1,000 rows, and 95% of them are collapsed via JavaScript when the page is
rendered. Each top-level table row has a link to expand all of the sub-rows
underneath via a small JavaScript function to expand/collapse DOM elements
with a certain id.
This page has been in use since Wicket 1.4.X, and went through all of the
various 5.X.0 and 6.X.0 versions with no issues. However, something changed
-- big time -- between Wicket 6.20.0 and Wicket 7.0.0. In Wicket 6.20.0,
the server-side page rendering takes about 6s, with another second or two of
rendering the HTML in the browser. In Wicket 7.0.0, this increases
dramatically to 158 seconds for server-side rendering (with the same one to
two second penalty for rendering in the browser).
I'm assuming that Wicket's internals changed a lot to support the new
Component Queuing functionality. I'm wondering if maybe these changes
accidentally degraded performance for large component trees in a single Page
(which unfortunately, is our main use-case). A colleague of mine put a
bunch of print statements in our code, and found out that some
WebMarkupContainer#add(); function calls were taking over 1 second each to
complete as the page is rendered (with performance degrading as more and
more components are added to the page).
Is anyone able to reproduce this issue, or hand any problems like this since
upgrading to Wicket 7.0.0? I wanted to check here before trying to put
together a Quickstart... Unfortunately, we are in a big crunch for the next
few months, so for the time being, we have just reverted to Wicket 6.20.0...
(and as a consequence, there's not much time allowed to spend debugging this
issue right now).
Thanks for anyone's input and help. I really appreciate it.
-- Aaron J. Garcia
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Performance Degredation for Adding Components in Wicket 7.0.0 vs.
Wicket 6.20.0
Posted by Martijn Dashorst <ma...@gmail.com>.
Thanks for doing this!
Martijn
On Mon, Sep 14, 2015 at 10:43 PM, Aaron J. Garcia <ag...@rentec.com> wrote:
>
>> I created an issue in JIRA,
>> attached a quick-start, and marked it as Major issue. In my opinion, this
>> should be moved to Critical or Blocker status though... I'm sure I'm not
>> the only one who adds that many components or attribute modifiers to a page
>> at one time.
>
> Forgot the link to the issue:
>
> https://issues.apache.org/jira/browse/WICKET-5981
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Performance Degredation for Adding Components in Wicket 7.0.0 vs. Wicket 6.20.0
Posted by "Aaron J. Garcia" <ag...@rentec.com>.
> I created an issue in JIRA,
> attached a quick-start, and marked it as Major issue. In my opinion, this
> should be moved to Critical or Blocker status though... I'm sure I'm not
> the only one who adds that many components or attribute modifiers to a page
> at one time.
Forgot the link to the issue:
https://issues.apache.org/jira/browse/WICKET-5981
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Performance Degredation for Adding Components in Wicket 7.0.0 vs. Wicket 6.20.0
Posted by "Aaron J. Garcia" <ag...@rentec.com>.
> Actually we have some perf tests in our tests suite and it doesn't show any
> noticeable degradation between #add() and #queue().
> Although I see now that it just println's the diff, but there is no
> assertion:
>
Hi Martin,
Thank you for your reply.
Yes, 158 seconds is slow! Instead of spending time profiling the issue in
our application-specific code, I made a quick-start. It turns out that this
issue is very easy to reproduce with a vanilla RepeatingView component (as I
had suspected).
In summary, Wicket 6.20.0 adds 5,000 rows x 6 columns + 5,000
AttributeModifiers [one per row] (i.e. 35,000 add() calls) in about 200
milliseconds. Wicket 7.0.0 takes about 10 seconds to add the same amount of
components to the hierarchy.
With 10,000 rows x 6 columns + 10,000 AttributeModifiers, (i.e. 70,000 add()
calls), Wicket 6.20.0 takes about 500 milliseconds to add all of the
components, while Wicket 7.0.0 takes about 40 seconds.
In my opinion, this is a huge performance degradation from 6.X.Y to 7.X.Y,
and is something that should be looked at. I created an issue in JIRA,
attached a quick-start, and marked it as Major issue. In my opinion, this
should be moved to Critical or Blocker status though... I'm sure I'm not
the only one who adds that many components or attribute modifiers to a page
at one time.
Thanks for your help. You can reach me here or via e-mail if you need me.
Regards,
Aaron J. Garcia
P.S. I looked at your performance test, and I think it should try and add
more than 250 contacts to the page...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Performance Degredation for Adding Components in Wicket 7.0.0 vs.
Wicket 6.20.0
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Sun, Sep 13, 2015 at 11:49 PM, Aaron J. Garcia <ag...@rentec.com>
wrote:
> Hello,
>
> I'm hoping someone here can help me. My organization uses Wicket as the
> framework for a fairly large internal web application.
>
> We have a page that renders a hierarchal data table. It's implemented with
> a RepeatingView for the table rows, and various WebMarkupContainers for the
> columns (each column's component for one row gets attached to a new
> WebMarkupContainer(rv.newChildId()) container). Anyway, the table has
> about
> 1,000 rows, and 95% of them are collapsed via JavaScript when the page is
> rendered. Each top-level table row has a link to expand all of the
> sub-rows
> underneath via a small JavaScript function to expand/collapse DOM elements
> with a certain id.
>
> This page has been in use since Wicket 1.4.X, and went through all of the
> various 5.X.0 and 6.X.0 versions with no issues. However, something
> changed
> -- big time -- between Wicket 6.20.0 and Wicket 7.0.0. In Wicket 6.20.0,
> the server-side page rendering takes about 6s, with another second or two
> of
> rendering the HTML in the browser. In Wicket 7.0.0, this increases
> dramatically to 158 seconds for server-side rendering (with the same one to
> two second penalty for rendering in the browser).
>
158secs is a lot!
It should be very easy for you to profile it if it is that slow.
I'd start by taking thread dumps - just do "kill -3 javaProcessId", e.g.
every seconds. This should show the slow threads.
Otherwise a proper profiler should help even further. I use YourKit and
JProfiler, but VisualVM should help too.
>
> I'm assuming that Wicket's internals changed a lot to support the new
> Component Queuing functionality. I'm wondering if maybe these changes
> accidentally degraded performance for large component trees in a single
> Page
> (which unfortunately, is our main use-case). A colleague of mine put a
>
Actually we have some perf tests in our tests suite and it doesn't show any
noticeable degradation between #add() and #queue().
Although I see now that it just println's the diff, but there is no
assertion:
https://github.com/apache/wicket/blob/master/wicket-core/src/test/java/org/apache/wicket/queueing/ComponentQueueingPerformanceTest.java#L94
> bunch of print statements in our code, and found out that some
> WebMarkupContainer#add(); function calls were taking over 1 second each to
> complete as the page is rendered (with performance degrading as more and
> more components are added to the page).
>
> Is anyone able to reproduce this issue, or hand any problems like this
> since
> upgrading to Wicket 7.0.0? I wanted to check here before trying to put
> together a Quickstart... Unfortunately, we are in a big crunch for the
> next
> few months, so for the time being, we have just reverted to Wicket
> 6.20.0...
> (and as a consequence, there's not much time allowed to spend debugging
> this
> issue right now).
>
> Thanks for anyone's input and help. I really appreciate it.
>
> -- Aaron J. Garcia
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>