Speed problem when TLS encrypted connection is used

[R-15000]

Hello,

We are doing speed and load tests using Redis in pub/sub broker mode and Hiredis C API.
The tests consists of continuously sending messages both ways from a client A to a client B using the broker.

We have a speed issue when sending messages when TLS encrypted connection is used.

Regarding our tests :

We have a client A which sends a message to the client B. The client B, after receiving the message from client A, replies to the client A from the message reception callback. We repeat this operation continuously to mesure the number of transactions per second.
To do so, we use a topic "client_A" for the client A to send the messages, the client B subscibes to this topic "client_A".
Also, the client B sends the messages to its own topic "client_B", the client A subscribes to this topic "client_B".

When we don't use TLS encrypted connection, everything works just fine. But when we set TLS encrypted connection, we have speed issues.

We tested with "short" messages with data of 400 bytes size and "long" messages with data of 70 000 bytes size.

We also tested several configurations. In our tests, we launched 1 to N client_A instances, with always only one client B.
We also used 1 to N commmunication channels of 2 topics between client B and each instance of client A.
Ex : 1 client A, 1 client B, 1 communication channel (2 topics) - 1 client A, 1 client B, 2 communication channels (4 topcis), 2 client A, 1 client B, 3 communication channels (6 topics), and so on (With always only one client B).

We tried with different numbers of client A and channels but it didn't help, we noticed the issue for the following configurations :

    - 1  client A, 1 client B, 1 communication channel (2 topics) : 100 messages/s, CPU 45% - Long messages
    - 1  client A, 1 client B, 1 communication channel (2 topics) : 265 message/s, CPU 5% - Short messages
    - 1  client A, 1 client B, 5 communication channels (10 topics) : 250 messages/s, CPU 99% - Long messages
    - 1  client A, 1 client B, 5 communication channels (10 topics) : 1390 message/s, CPU 16% - Short messages
        - 1 client A, 1 client B, 10 communication channels (20 topics) : 250 messages/s, CPU 98% - Long messages
        - 1 client A, 1 client B, 10 communication channels (20 topics) : 2700 messages/s, CPU 25% - Short messages

        - 5  client A, 1 client B, 1 communication channel (2 topics) : 250 messages/s, CPU 99% - Long messages
    - 5  client A, 1 client B, 1 communication channel (2 topics) : 1430 messages/s, CPU 18% - Short messages
    - 5  client A, 1 client B, 5 communication channels (10 topics) : 250 messages/s, CPU 98% - Long messages
    - 5  client A, 1 client B, 5 communication channels (10 topics) : 5700 messages/s, CPU 49% - Short messages
        - 5  client A, 1 client B, 10 communication channels (20 topics) : 250 messages/s, CPU 98% - Long messages
    - 5  client A, 1 client B, 10 communication channels (20 topics) : 8650 messages/s, CPU 63% - Short messages

As we can see, we reach a limit of 250 messages/s for long messages, with almost 100% CPU used.

• Please note when the client B receives a message, the receive callback is triggered, and a thread is created to reply to the instance of client_A which sent the message. Threads are used in client B only.
  The threads allow several messages to be processed and replied simultaneously.
  We had the same problem even without the usage of threads.

If we don't use TLS encrypted connection, everything works fine, we don't have that speed issue.

We are trying to find the origin of this issue which appears only when we use TLS in our case.
We know TLS can decrease the performance, but probably not that much. Seems we reached a kind of limitation somewhere.

In the client B (and also the client A) program, we use 2 Hiredis contexts, one for message reception, one for message sending.

Any help would be appreciated.

Thank you.