[Libwebsockets] EXT: Re: count_threads in client side

Andy Green andy at warmcat.com
Mon Nov 30 15:40:12 CET 2020

On 11/30/20 2:26 PM, Peiffer Eric wrote:
> Hi,
> 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 don't think anyone can help you better than yourself with your own 
code in front of you...

> I can neither install gdb no open all websocketes traces. And I can not 
> reproduce this issue in my labs.

Well, it sounds like it feels there is always something to do and the 
event loop should not be idle.  It's not how it should be, or actually 
is if you run the examples even under load, but, IIUI  does it actually 
make any trouble?  You are going around the event loop more than you 
need to, but IIUI you ARE going around the event loop and becoming aware 
of events and servicing them.

If your event loop is busy, it's not competing with this spinning, it 
will only spin instead of idle IIUI.  Whatever work was needed is still 
done immediately.  So the only impact is one thread never enters an idle 
poll wait for any real time.

If it's linux, you can use perf top -p <pid> to get some insight into 
where it spends its time without stopping the process.

> 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.

Any particular reason to not do it with one context?  There is no 
conflict with a single context doing client connections and listening 
for incoming connections on vhosts as a servers as well.

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

AFAIK, no.  The contexts only take care about sockets / fds that their 
loop knows about... since fd numbers are a processwide resource, if one 
loop is managing a particular fd, the other thread will never be told 
about it.  So no way to conflict.

There are other processwide things like library bindings, eg, openssl, 
but modern openssl can be used OK by multiple threads.


> Regardes
> Eric
> ------------------------------------------------------------------------
> *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
> https://libwebsockets.org/git/libwebsockets/tree/minimal-examples/http-server/minimal-http-server-smp 
> <https://libwebsockets.org/git/libwebsockets/tree/minimal-examples/http-server/minimal-http-server-smp>
> 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
> then.
> 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.
> -Andy
> _______________________________________________
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
> https://libwebsockets.org/mailman/listinfo/libwebsockets

More information about the Libwebsockets mailing list