[Spice-devel] Traces of performance issues

[Yonit Halperin]

On 07/25/2011 07:32 AM, John A. Sullivan III wrote:
> 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.
>
Nagle is disabled. However, as I wrote on the web page, I think it is 
bad in some circumstances.
> 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
>
>
Thanks for all the information. We need to check if over WAN, replacing 
ZLIB wrapped GLZ  with PNG will give us better compression ratio. Sounds 
like a good idea.

Thanks,
Yonit.