Hi, On Sun, Sep 13, 2015 at 11:49 PM, Aaron J. Garcia <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > >
