[Libwebsockets] CPU-intensive and I/O-intensive job in LWS

Andy Green andy at warmcat.com
Thu Oct 4 09:24:27 CEST 2018



On 04/10/18 15:06, Xi Chen wrote:
> Thanks for your insights Andy.
> 
> Unfortunately the platform is some RTOS running on tiny MCU, which is 
> not powerful at all.

Even RTOS have a thread concept though.

> The thread pool approach is not possible for me.

If it's not pthreads or pthreads-compatible, then no.

> For TLS, seems the solution is to speed it up by using other optimized 
> libraries?

Not if mbedtls is the only thing on your platform.  1 x TLS will cost 
whatever it costs timewise, but if you have multiple connections coming, 
you should look at HTTP/2.  It can provide all your assets like pictures 
etc on the same TLS connection.  This works well on ESP32 it should work 
on your box.

> For flash I/O, might need to sacrifice RAM by maintaining another copy 
> of received data, and write it later to flash by different task?

You can do that, or read again more closely about using a second thread 
+ rx flow control.

> Have you helped with other guys on similar topics before, i.e., porting 
> LWS on resource tight platforms? I do notice that there is esp32 
> support, but not many related sample apps I can find in this area.

Nobody pays me to look at it... if people like yourself who feel I 
should be spending my life doing that or other stuff want to actually 
fund it (or contribute it directly...), it can happen.

-Andy

> On Wed, Oct 3, 2018 at 11:40 PM Andy Green <andy at warmcat.com 
> <mailto:andy at warmcat.com>> wrote:
> 
> 
> 
>     On 04/10/18 14:14, Xi Chen wrote:
>      > Hi, Andy
>      >
>      > I need help with dealing the following scenarios:
> 
>     What is the platform, something really weak?
> 
>      > [Server case - CPU]
>      > - With mbedtls, the crypto job might be CPU-intensive, which will
>     block
>      > the LWS thread. This affects the concurrency capability supported by
>      > LWS, right? Is it by design of LWS?
> 
>     Lws is nonblocking and singlethreaded, so yes it is by design.  You
>     can't stop the event loop thread by spinning it in your code without
>     stopping handling of events... this is a characteristic of all event
>     loops not just lws.
> 
>     So you have to adapt your design if you won't block the event loop.
> 
>      > [Server case - I/O]
>      > - Suppose server receives a POST request and need to save the
>     data on
>      > flash. I believe the flash write is blocking most likely, and is not
>      > recommended to run in LWS callbacks. In this case, what is the
>      > recommended way to deal with flash write in efficient way?
> 
>     ... it depends on your platform resources and situation.
> 
>     If your platform is not very constrained, there's no good reason to use
>     mbedtls when OpenSSL has many optimized implementations for common
>     platforms.  OpenSSL is literally 20+x faster for common tls operations
>     on x86_64.  (And OpenSSL maintainers are not high on NIH.)
> 
>     The write to serial flash situation you describe exists on the lws
>     ESP32
>     stuff, when you upload the OTA firmware.  But because it's a modal
>     firmware upgrade type situation, it's OK to block other things.
> 
>     To solve it, you have to move the slow activity to another thread or
>     process.  That could take the form of buffering the data to be written
>     in RAM and writing it separately (obviously the wisdom of that depends
>     entirely on device resources...), or starting a thread when you see the
>     requested task needs it and using rx flow control to modulate accepting
>     new data against the progress of writing the last lot.  But I have not
>     spent any time on http/2 rx flow control yet so this is only good
>     for h1
>     as it stands.
> 
>     In the case the pattern is a client request triggers something that
>     takes a long time to complete before generating output, if your
>     platform
>     is strong enough to support pthreads then look at threadpool:
> 
>     https://libwebsockets.org/git/libwebsockets/tree/lib/misc/threadpool
> 
>     This lets a wsi defer answering on a connection until something it
>     wanted to execute completed on a thread from a threadpool.  The event
>     loop continues on as soon as the job is queued on the threadpool.  And
>     the job can sync with the original wsi WRITEABLE callback when it is
>     ready.  The advantage is lws absorbs ALL the thread synchronization
>     stuff, you don't have to use any pthreads in your code.
> 
>     There's a minimal example for it here:
> 
>     https://libwebsockets.org/git/libwebsockets/tree/minimal-examples/ws-server/minimal-ws-server-threadpool
> 
>     Gitohashi (the git web interface those links use) runs everything via
>     threadpool, because stuff like the blame view can be slow to generate.
>     By using threadpool a slow job doesn't cause any delay for other
>     clients
>     (until the pool of threads is wholly occupied).  And it can be
>     running n
>     slow jobs on n cores that way, giving a speedup overall.
> 
>     -Andy
> 
>      > Thanks
>      > -Xi
>      >
>      >
>      > _______________________________________________
>      > Libwebsockets mailing list
>      > Libwebsockets at ml.libwebsockets.org
>     <mailto:Libwebsockets at ml.libwebsockets.org>
>      > https://libwebsockets.org/mailman/listinfo/libwebsockets
>      >
> 


More information about the Libwebsockets mailing list