<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 28, 2016 at 8:43 PM, Greg Sheremeta <span dir="ltr"><<a href="mailto:gshereme@redhat.com" target="_blank">gshereme@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi everyone,<div><br></div><div>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.</div><div><br></div><div>After some research, we determined that the primary cause of this sluggishness was memory leaks. </div><div><br></div><div>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.</div><div><br></div><div>Over the course of several hours with the browser window open, users should see no sluggishness at all.</div><div><br></div><div>[*] 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.</div><div><br></div><div>If you're interested in UI performance testing, continue reading. If not, you can stop here :)</div><div><br></div><div>.....</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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!</div><div><img src="cid:ii_1586a7f8cf2ed4c9" alt="Inline image 1" width="645" height="398" style="margin-right: 25px;"><br></div><div>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.</div><div><img src="cid:ii_ivk6qmd81_1586a84fde4421d2" width="963" height="261" style="margin-right: 25px;"><br><br></div><div>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.</div></div></blockquote><div><br></div><div>I'm wondering if we have any data about de-rpc vs. gwt-rpc under WAN conditions. With latency (say, 70ms, based on [1]) and possibly some packet loss (0.5% should suffice). </div><div>Y.</div><div><br></div><div>[1] <a href="http://www.internettrafficreport.com/30day.htm">http://www.internettrafficreport.com/30day.htm</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><img src="cid:ii_iw2ezvzz2_158ac38245554f92" width="1241" height="448" style="margin-right: 25px;"><br><br></div><div>Reply with any questions or concerns. Thanks!<br></div><div><br></div><div>Best wishes,</div><div>Greg</div><div><br></div><div>[1] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1368101" target="_blank">https://bugzilla.redhat.co<wbr>m/show_bug.cgi?id=1368101</a></div><div>[2] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1388462" target="_blank">https://bugzilla.redhat.co<wbr>m/show_bug.cgi?id=1388462</a></div><span class="gmail-HOEnZb"><font color="#888888"><div><br></div>-- <br><div class="gmail-m_5535695013864137774m_5749232511781752611gmail_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>
</font></span></div>
<br>______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br></blockquote></div><br></div></div>