[ovirt-devel] performance improvements and gwt-rpc switch

Thu Dec 1 09:30:19 UTC 2016

looks like great work has been done here.
following QE validation and internal customers input assuming feedback is
very positive and regressions are covered , i would like to take this
information to our customers.
would probably worth a post on rhev-tech. what are the exceptions for the
performance boost due to the changes on 3.6 branch?

On Wed, Nov 30, 2016 at 7:46 PM, Vojtech Szocs <vszocs at redhat.com> wrote:

> Thanks Greg for the excellent write-up!
>
> oVirt WebAdmin UI is quite complex, with lots of abstractions (the GWT
> technology being a Java-on-top-of-Web-APIs abstraction itself) as well
> as many features (and lots of dialogs..) so this task wasn't easy, but
> I guess we managed to get UI into a stabilized state now.
>
> Dialogs (non-singleton by design) were a major source of memory leaks,
> so we added UI infra to ensure automatic dialog cleanup.
>
> In 4.2, we'd like to upgrade GWT SDK version to latest stable (2.8.x)
> which will hopefully improve GWT compiler performance and, importantly,
> allow us to use Java 8 language features in our GWT UI code.
>
> There's still potential for improvement, we're tracking that through:
>
>   [tracker] oVirt UI performance improvements
>   https://bugzilla.redhat.com/1378935
>
> (some IE-specific improvements are already submitted as part of ^^)
>
> Regards,
> Vojtech
>
>
> ----- Original Message -----
> > From: "Greg Sheremeta" <gshereme at redhat.com>
> > To: "devel" <devel at ovirt.org>
> > Sent: Monday, November 28, 2016 7:43:27 PM
> > Subject: [ovirt-devel] performance improvements and gwt-rpc switch
> >
> > Hi everyone,
> >
> > For the upcoming oVirt 4.1, the UX team has been focused hard on webadmin
> > performance improvements. There have been some reports [1] [2] of UI
> > sluggishness in both 3.6 and 4.0, usually after the browser had been open
> > some time, and usually in scale environments.
> >
> > After some research, we determined that the primary cause of this
> > sluggishness was memory leaks.
> >
> > We embarked on several weeks of hunting down memory leak bugs and
> squashing
> > them. Alexander Wels and Vojtech Szocs led this work, and I helped test
> the
> > performance of each patch as they created them. As they created patches
> to
> > squash leaks, performance kept getting better and better. Today we've
> merged
> > the last of our patches [*], and I'm happy to announce that we are now
> > seeing much better UI performance on 4.1-master and 4.0.6.
> >
> > Over the course of several hours with the browser window open, users
> should
> > see no sluggishness at all.
> >
> > [*] This last patch switches oVirt from using de-rpc to gwt-rpc in the
> > frontend. This improves performance, but it also allows us to upgrade to
> GWT
> > 2.8. We'd been previously blocked on that.
> >
> > If you're interested in UI performance testing, continue reading. If
> not, you
> > can stop here :)
> >
> > .....
> >
> > To verify our performance improvements, we took some simple measurements
> > using selenium webdriver. The tests were unscientific, but very helpful.
> We
> > ran a webdriver flow through oVirt that clicked some buttons and tabs and
> > refreshed some grids. We did it a few hundred or thousand times. The
> tests
> > were run using stubbed hosts (ovirt-vdsmfake) so that only the engine
> and UI
> > were under test.
> >
> > Below are the important takeaways. The x axis is time, and each point on
> a
> > graph is a loop through the same webdriver flow. The (ms) y axes are
> > response times, and memory is in MB.
> >
> > In this graph, we compare oVirt 4.1 with and without our most impactful
> patch
> > applied. As you can see, with the patch applied, response time stays flat
> > for 200 loops of my test script over the course of 18 and 43 minutes.
> > Without the patch applied, response time quickly degraded such that 200
> > loops of my test script took 1 hr 2 minutes vs. 18 minutes with the patch
> > applied -- a 66% improvement!
> >
> > In this graph [ignore the spike], we tested oVirt hard for 6 hours 25
> minutes
> > (2000 loops). As you can see, the response times stay relatively flat
> over 6
> > hours! This is a great improvement. Do note that the memory is still
> > growing, albeit much more slowly now. You can see towards the end of this
> > run, maybe around hour 5, that the deviation starts to go up (the line
> > thickens). Takeaway: maybe refresh your browser after many hours of
> having
> > webadmin open. But, this is a stress test -- I'm betting users won't
> notice
> > this slowdown after even 6 hours of regular webadmin use or idling.
> >
> > 
> > Last, here is a graph that shows gwt-rpc performing slightly better than
> > de-rpc. Memory consumption is about the same -- gwt-rpc is just a faster
> rpc
> > implementation.
> >
> > 
> > Reply with any questions or concerns. Thanks!
> >
> > Best wishes,
> > Greg
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1368101
> > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1388462
> >
> > --
> > Greg Sheremeta, MBA
> > Red Hat, Inc.
> > Sr. Software Engineer
> > gshereme at redhat.com
> >
> > _______________________________________________
> > Devel mailing list
> > Devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20161201/1dcd4888/attachment-0001.html>