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

Xi Chen leon6827chix at gmail.com
Thu Oct 4 20:46:18 CEST 2018


Andy,

I have one more quick question regarding mbedtls behavior.
Given that one TLS frame may be fragmented at TCP layer, mbedtls might need
to call multiple recv() before it can decrypt the packet.
I do notice that lws_http_client_read eventually calls mbedtls_ssl_read
which has a handshake loop, i.e., mbedtls_ssl_handshake. Does this mean
that LWS thread will be blocked until all related TCP segments has been
received and decryption is done?

On Thu, Oct 4, 2018 at 12:24 AM Andy Green <andy at warmcat.com> wrote:

>
>
> 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
> >      >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20181004/8b5191ba/attachment.html>


More information about the Libwebsockets mailing list