[Libwebsockets] CPU-intensive and I/O-intensive job in LWS
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
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.
> 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
> > 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
> 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
> is strong enough to support pthreads then look at 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:
> 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
> (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.
> > 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