[Libwebsockets] Queries regarding the throughput and latency

Andy Green andy at warmcat.com
Wed Feb 22 06:09:29 CET 2017



On February 22, 2017 1:32:01 PM GMT+09:00, Senthil Kumar <senthil.mca.ceg at gmail.com> wrote:
>Hi LWS-Team,
>
>I started learning about WebSockets and going through the libwebsockets
>library.
>
>I have few queries about the minimum and maximum throughput the library
>can
>achieve.
>
>What is the throughput which we can achieve by using the library (For
>ex,
>sending 10MB of data from client to server) and what are the factors
>which
>may affect the throughput keeping the network traffic and load aside?
>
>FYI, i tested my libwebsockets powered client sample written in C which
>echoes 10MB data to echo.websocket.org over 443. The *average
>throughput is
>3.5Mbps* for sending 10MB data and receiving it back.
>
>Is there any claim or benchmark data exist for this?
>
>And also please suggest standard ways to measure the throughput.

Just measure it yourself unders conditions matching how you plan to use it... if you are a long way from the test server, you will get different results than test against localhost.  Another guy with different network situation to same server, or different powered machine to localhost will get different results.  So these numbers are difficult to understand the meaning of, or to compare.

Unless your end use involves firing small packets at an echo server they also may not reflect the performance of your system either.

The main constraint on lws is the size of the send unit lws will attempt to send in one go, this is set by both the context info at creation time

	unsigned int pt_serv_buf_size;
	/**< CONTEXT: 0 = default of 4096.  This buffer is used by
	 * various service related features including file serving, it
	 * defines the max chunk of file that can be sent at once.
	 * At the risk of lws having to buffer failed large sends, it
	 * can be increased to, eg, 128KiB to improve throughput. */

and the selected protocol

	size_t rx_buffer_size;
	/**< lws allocates this much space for rx data and informs callback
	 * when something came.  Due to rx flow control, the callback may not
	 * be able to consume it all without having to return to the event
	 * loop.  That is supported in lws.
	 *
	 * This also controls how much may be sent at once at the moment,
	 * although this is likely to change.
	 */

Increasing these sizes lets you shovel more data at once into your tcp connection window, if it can take it.  If the kernel can only take a small amount, lws will buffer it for you.  So you have to tune this to reflect the amount of data you need to send and the bandwith your connection typically has, to get the best results.

Ws ping / pong is restricted to 126 bytes or so of payload btw, unless that reflects your usecase well, behaviour in your real system is not likely to bear any relationship to this kind of synthetic test.

-Andy

>Thanks & Regards,
>Senthil Kumar G S



More information about the Libwebsockets mailing list