You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pulsar.apache.org by Andrey Yegorov <ay...@apache.org> on 2023/03/16 23:59:48 UTC

[Question] [java client] CPU-intensive code on io threads

Hi,

While looking through the code/thread dumps I noticed that decompression of
compressed payload happens on pulsar-client-io threads
Specifically:
https://github.com/apache/pulsar/blob/80c5791b87482bee3392308ecef45f455f8de885/pulsar-client/src/main/java/org/apache/pulsar/client/impl/ClientCnx.java#L495-L505
handleMessage runs on the pulsar-client-io thread (used by netty)
and consumer.messageReceived() will do decompression of the payload on
the netty thread, which is a bad practice in my understanding.

I am not very familiar with client's thread pools, are there any reasons
not to movemessageReceived() to internalPinnedExecutor, like

consumer.internalPinnedExecutor.submit(() -> {
     consumer.messageReceived(cmdMessage, headersAndPayload,
ClientCnx.this);
 });

--
Andrey

Re: [Question] [java client] CPU-intensive code on io threads

Posted by Matteo Merli <ma...@gmail.com>.
Adding that executor will introduce 2 additional context switches which
would impact the performance.

> will do decompression of the payload on
> the netty thread, which is a bad practice in my understanding.

I would not categorize this as an anti-pattern: io-threads are there to do
io work, and serialization & compression are definitely part of that. The
important part is to avoid any blocking operations.



--
Matteo Merli
<ma...@gmail.com>


On Thu, Mar 16, 2023 at 5:01 PM Andrey Yegorov <ay...@apache.org> wrote:

> Hi,
>
> While looking through the code/thread dumps I noticed that decompression of
> compressed payload happens on pulsar-client-io threads
> Specifically:
>
> https://github.com/apache/pulsar/blob/80c5791b87482bee3392308ecef45f455f8de885/pulsar-client/src/main/java/org/apache/pulsar/client/impl/ClientCnx.java#L495-L505
> handleMessage runs on the pulsar-client-io thread (used by netty)
> and consumer.messageReceived() will do decompression of the payload on
> the netty thread, which is a bad practice in my understanding.
>
> I am not very familiar with client's thread pools, are there any reasons
> not to movemessageReceived() to internalPinnedExecutor, like
>
> consumer.internalPinnedExecutor.submit(() -> {
>      consumer.messageReceived(cmdMessage, headersAndPayload,
> ClientCnx.this);
>  });
>
> --
> Andrey
>