[Libwebsockets] EXT: Re: count_threads in client side

Peiffer Eric eric.peiffer at al-enterprise.com
Mon Nov 30 15:26:29 CET 2020


I'am yet my problem of 100%CPU in the thread that run the while loop calling the lws_service function:

while (n >= 0 && !interrupt)
    n = lws_service(context, 0);

I can not debug properly my code because the system is on production and I can neither install gdb no open all websocketes traces. And I can not reproduce this issue in my labs.

I have two king of lws_service loop:
One that open thousand of client connection
The second that open a server connection

The two  loop used two separate context and also separate call back.

Since this two loops run in the same process could there be concurences problems?



De : Andy Green <andy at warmcat.com>
Envoyé : jeudi 22 octobre 2020 18:21
À : Peiffer Eric <eric.peiffer at al-enterprise.com>; libwebsockets at ml.libwebsockets.org <libwebsockets at ml.libwebsockets.org>
Objet : EXT: Re: [Libwebsockets] count_threads in client side

** External email - Please consider with caution **

On 10/22/20 4:44 PM, Peiffer Eric wrote:
> Hi,
> My application use libwebsockets 4.1 on debian 10 and handle thousands
> of web socket connections.
> We have notice that when we approach the 15000 connections de thread
> that run the message loop take almost 100%  of the CPU.
> This is because client connections receive xmpp ping each minute, not in
> the same time but may be 1000 connexions receive xmpp ping then 1 second
> later the next 2000, and so on ,...

Right... it sounds pretty busy.

> In order to decrease the CPU usage is it possible to use a pool of
> several threads maybe 2 or 3 in order to handle the 15000 client
> connections. Can I use the count_threads paramaters in the info struct
> in order to handle more than one thread in the context that handle
> client connections?
> If the answer is yes how are managed the connections:
> When a connection is opened does it always stay in the same thread?

It's possible to have n event loops, by building with, eg, LWS_MAX_SMP=8
and following the approach here


As a server, all threads can listen on the same port (at least on
Linux), the incoming connections check which event loop is the least
busy, and then migrate to that.

LWS_MAX_SMP > 1 enables various internal lws pthread locking, but you
will have to adapt your user code to understand that although in a
particular event loop thread all the lws calls are serialized as usual,
for multicore or multi-hardware-thread machines the same user protocol
handler code is in truly simultaneous use by multiple event loop threads

That means that you must also add locking to protect your data
structures from simultaneous change from multiple event loops, the
example shows the general way.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20201130/bafcc518/attachment.htm>

More information about the Libwebsockets mailing list