[Libwebsockets] performance client vs server

jb justinbeech at gmail.com
Mon Nov 7 04:40:37 CET 2016

Hi Andy,
I managed to get it about 6x faster by inserting this
chunk of code into lws_handshake_client.

Sorry I'm not too good with diffs or pull requests yet ..

However you can see from the screen shot that if one
gulps payload when the parser is in its most common state
then there is massive performance improvement for
extended runs of large payloads that are not masked.

Before: Server 10% client 100% - throughput maybe 1.5 gigabit
After: Server 50% client 100% - throughput about 6-7 gigabit.

The new code is in braces. In lws_handshake_client.
this stops most of the character by character calling
of lws_client_rx_sm
which has local variables and a lot of popping and pushing
and if()s.  Similar performance if you just gulp 128 byte
chunks, rather than "len" and then let lws_client_rx_sm()
clean up the remainder.

I've no idea what this breaks! but yeah the gain is available.

On Mon, Nov 7, 2016 at 1:40 PM, Andy Green <andy at warmcat.com> wrote:

> On Mon, 2016-11-07 at 13:12 +1100, jb wrote:
> > Using a modified fraggle.c, removing deflate, increasing the message
> > size to batches of 32k, removing the generation of random data and
> > the checksums, I see that when the client runs at 100% cpu the server
> > is only running at 10% cpu. (fraggle.c is arranged so when a client
> > connects the server sends a bunch of messages).
> >
> > Doing a quick profile it looks like all the client cpu time is taken
> > up by lws_client_rx_sm which appears to be a character by
> > character state machine for receiving bytes.
> >
> > It isn't totally clear to me why the server is 10x faster than the
> > client at sending data than the client is at reading data. If the
> > server sends a 32k block of zeros as a binary message, at some point
> > isn't there a payload length and a payload of 32k does each byte have
> > to be processed individually on one side but not the other?
> Take a look at this
> https://github.com/warmcat/libwebsockets/blob/master/lib/parsers.c#L146
> 1
> On the server side, the equivalent parser got a patch optimizing the
> bulk data flow.
> If you'd like to port that to the client side, patches are welcome.
> -Andy
> > thanks.
> > _______________________________________________
> > Libwebsockets mailing list
> > Libwebsockets at ml.libwebsockets.org
> > http://libwebsockets.org/mailman/listinfo/libwebsockets
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20161107/237a7283/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2016-11-07 at 2.37.45 pm.png
Type: image/png
Size: 196361 bytes
Desc: not available
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20161107/237a7283/attachment-0001.png>

More information about the Libwebsockets mailing list