[Libwebsockets] lws_write speed
andy at warmcat.com
Wed May 18 13:55:50 CEST 2016
On 05/18/2016 07:46 PM, Denis Osvald wrote:
> On 05/18/2016 01:38 PM, Andy Green wrote:
>> On 05/18/2016 07:08 PM, Denis Osvald wrote:
>>> Hi all,
>>> On 05/16/2016 09:33 PM, Pierre Laplante wrote:
>>>> In the example of the server, you are using malloc to copy the data
>>>> before using lws_write as in:
>>>> Is there another way to do this ?
>>> Andy, have you looked at the writev syscall, if it's usable in this
>>> It accepts multiple buffers, so it could maybe use the first buffer for
>>> the padding thus not requiring user to have padding space in their
>>> buffer. It would send them both at once in one writev call then.
>>> Maybe it's worth exploring?
>> I think it doesn't help with the basic problem, which is that the kernel
>> must restrict how much memory it sets aside for buffering a specific
>> networking connection.
>> Actually writev() semantics seem to be no different than write() in the
>> sense it will inform you afterwards how much it actually used
>> RETURN VALUE
>> On success, readv() and preadv() return the number of bytes read;
>> writev() and pwritev() return the number of bytes writ‐
>> ten. On error, -1 is returned, and errno is set appropriately.
>> The basic problem is that the kernel may conclude it only wants to take
>> a little of your data into kernelside buffers based on global memory
>> situation and the conditions on the specific connection.
>> writev() won't magically solve that if I understood it, it's more about
>> matching kernelside scatter-gather semantics when there is no special
>> restriction on buffering from the driver (ie, storage).
> Well, you're right that it wouldn't resolve any of the performance or
> bufferring issues.
> The only thing that I see writev() helping with is library users not
> having to copy data into a new buffer with padding. This would help when
> data comes from other sources. E.g. some app uses lws and some libfoo
> which allocates and gives back void* foodata + foolen, then app has to
> malloc + memcpy because libfoo doesn't provide in-place providing of
> data where app would have padding in the buffer as well.
Agreed, but only if *writev() actually gets the kernel to take the
data*. When it doesn't, because it's regulated by the network stack and
the dynamics of a specific connection, we will be back in the same boat.
If I understood it the basic situation is unrelated to our having the
data in multiple, scatter-gather buffers, which is what this is designed
for, and is related to the kernel / network stack refusing to take on
our glut of data on that connection: the amount it does take will be the
same for write() or writev() doing the asking since writev() /
scatter-gather semantics doesn't change the actual problem of parking
the connection data kernelside.
lws_write() will destroy the incoming data anyway for client write case
since it'll XOR it as required by ws, in-place. If the data's in a
linear buffer and only for this connection, you only need to arrange
LWS_PRE padding before the very start of the buffer, it'll trash a bit
of already-sent data behind the 'cursor' in the buffer for the next tranche.
More information about the Libwebsockets