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

Thu Dec 1 15:27:07 UTC 2016

I'm working on 3.6 now. My expectation is that we can speed it up a bit,
but it'll never be as fast as 4.0.6/4.1. Unless we decide to commit time to
it, in which case we've proven that it can be done, it's just a matter of
resources.

Greg

On Thu, Dec 1, 2016 at 4:30 AM, Moran Goldboim <mgoldboi at redhat.com> wrote:

> 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
>>
>
>

-- 
Greg Sheremeta, MBA
Red Hat, Inc.
Sr. Software Engineer
gshereme at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20161201/80cb821d/attachment-0001.html>