[Spice-devel] Traces of performance issues

[John A. Sullivan III]

On Sun, 2011-07-24 at 08:33 +0300, Yonit Halperin wrote: 
> On 07/22/2011 02:33 PM, John A. Sullivan III wrote:
> > As mentioned in my last email, I have taken several traces revealing
> > performance issues, BSOD, and lost mouse scroll events.
> >
> > Performance still seems to be a function of bandwidth.  We are being
> > detected as low bandwidth:
> > main_channel_handle_parsed: net test: latency 52.512000 ms, bitrate
> > 4826250 bps (4.602671 Mbps) LOW BANDWIDTH
> > and
> > main_channel_handle_parsed: net test: latency 52.634000 ms, bitrate
> > 1980818 bps (1.889055 Mbps) LOW BANDWIDTH
> >
> > Yaniv's dissector shows we are using zlib compression.
> >
> > However, the bandwidth difference between RDP and SPICE for the same
> > activity is startling even when accounting for the roughly 272KB sent to
> > determine bandwidth.
> >
> > The activity I was tracing was connecting, logging in to a running
> > session with Zimbra web client open, creating an appointment, and then
> > tagging it.  Tagging is one of those comment events that is noticeably
> > slower in SPICE than RDP.
> >
> > Here are the redacted notes about each trace to show only the method and
> > byte counts:
> >
> > Connect to running Windows session via RDP (xfreedrp) and create and tag
> > a Zimbra appointment
> > xfreerdp -z -x b -d PACAD -f -u uid 172.29.1.133&
> > Total bytes to tag: ca. 27.5KB
> > Total bytes: 581KB
> >
> > Connect to running Windows session via SPICE and create and tag a Zimbra
> > appointment
> > spicec --host 172.29.1.124 --port 5900 --disable-effects all -f&
> > Total bytes to tag: ca. 183KB
> > Total bytes: 4083KB - 272K for SPICE ping = 3811KB
> >
> > Connect to running Windows session via SPICE and create and tag a Zimbra
> > appointment
> > spicec --host 172.29.1.124 --port 5900 --disable-effects all -f
> > --color-depth 16&
> > This differed from all other traces in that it did not login but
> > immediately opened to Zimbra web client
> > Total bytes to tag: ca. 178KB
> > Total bytes: 1911KB - 272K for SPICE ping = 1639KB
> >
> > 6.5 times the bandwidth for the identical operation.
> >
> > Why such a startling difference? Is this a configuration issue or a
> > protocol issue?
> >
> > Again, I know little about the technology and even less about the code
> > and I recognize that SPICE brings the beauty of portability as opposed
> > to RDP or NX.  Nonetheless, I noticed this on the NoMachine site about
> > NX which is still our speed champion by far.  It concerns their
> > advantages over zlib compression - the type we are using.  I wonder if
> > we might be able to learn something from their work.  From
> > http://www.nomachine.com/documentation/building-components.php
> >
> Hi,
> we don't use Zlib as the first line of compression:
> When the bandwidth is not limited we use two methods for compression: 
> QUIC & GLZ. They are both lossless. Quic is based on predictive encoding 
> and is more suitable for real-life bitmaps. GLZ is dictionary-based 
> (LZ), and works better on artificial (less random) bitmaps.
> When the bandwidth is LOW, we wrap GLZ encoded bitmaps with ZLIB, and 
> when it is possible, we compress bitmaps with JPEG instead of QUIC (more 
> cpu, but lossy). We can't always use JPEG, since we perform the 
> rendering on the client side, and not all the rendering commands will 
> suffer a lossy bitmap.
> In addition we use caching of bitmaps.
> 
> However, we still have room for improvements. Some are addressed here 
> http://spice-space.org/page/EnhancePerf
> 
> Can you please send the wireshark trace for the tagging events?
> 
> Thanks,
> Yonit.
> > "nxproxy is a "specialized" compressor. By "understanding" the X
> > protocol it is able to perform many optimizations on the produced X
> > traffic. It adapts bandwidth consumption according to network conditions
> > and, by only compressing what is not cached by the remote proxy, it
> > reduces the compression overhead to a minimum. By comparison, nxproxy is
> > able to consume 1/10th of the CPU used by ZLIB compression built in SSH,
> > while still compressing better by a factor of 10."
> >
> > I'd gladly take a tenfold reduction in bandwidth.  That would put it far
> > under RDP! Then again, perhaps we are already doing what they describe.
> > Thanks all and please let me know if you'd like copies of the traces -
> > John
> >
<snip>
Thanks very much for the explanation and link, Yonit.  I've sent the
traces and notes directly to you.

I found the comment about "Utilization of bitmaps that are almost
identical" particularly interesting.  I wonder if that is what we are
seeing in a number of our applications.  From the user's perspective, it
almost seems like buffering; we type something or click something, there
is a delay, and suddenly all the changes appear at once.  That's why I
asked early on if Nagle was not being disabled.  I wonder if it is this
whole page painting issue.

If there is a problem using jpeg because of client size rendering, would
it make sense to switch to server side rendering in situations where a
large percentage of the screen would be better served by jpeg?

For whatever it is worth, we have found a noticeable increase in NX
performance and screen clarity when we switch from their 16m-jpeg
packing to 16m-png-jpeg.  I do not know what it does but, perhaps, we
can learn something from it.  Of all the solutions we have tested so
far, and we have tested many, they are still the performance champion.
Thanks - John