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