Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Websocket server slow in sending messages under load

Hi,

On Thu, Jan 21, 2021 at 2:06 PM Abhirama <abhirama@xxxxxxxxx> wrote:
>
> Hi,
>
> We're using the Jetty Websocket server (version=9.4.35) in our application. We have a scenario where we have about a hundred messages (each of size about 2KB to 4KB) to be sent out to a remote client.
>
> We're using the async write method RemoteEndpoint.sendString(message, new WriteCallback() { ... } ).
>
> What we're noticing is a lot of time elapsing between the message getting queued and the message being processed and flushed.
>
> Here's an example:
>
> Jan 21, 2021 @ 06:59:36.981 ExtensionStack DEBUG container-22894 Queuing TEXT[len=3953,fin=true,rsv=...,masked=false]
> ...
> Jan 21, 2021 @ 07:09:25.841 ExtensionStack DEBUG qtp1220759559-343 Processing TEXT[len=6323,fin=true,rsv=...,masked=false]
>
> That's almost 7 mins elapsed between the two log lines!

Not sure I understand this?
The message is not the same (as the second log line shows a larger
message length).

If there was *no other* log lines between those 2 lines, then it could
be that the server could not write to the client because the client
was not reading and the connection went into TCP congestion.
If that was the case, then I would expect the idle timeout to close
the connection. By default it is 30 seconds. Did you change it to be
more than 7 minutes?

Other than that, it could be a long GC pause (did you check the GC logs)?

Lastly, it could be an OS pause, for example due to swapping or THP reclamation.

> I've gone through the Jetty code a little bit and suspect it could be because of the synchronized block within the ExtensionStack::offerEntry or ExtensionStack::pollEntry methods.

Unlikely.

> I must be doing something wrong because sending out a few hundred messages on a 2CPU/4GB RAM VM shouldn't be a large load!

Indeed, if the client reads them. Otherwise the server blocks because
of TCP congestion.

-- 
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.


Back to the top