Slow consume

I handle load test by use server 48 core cpu,
and there are server for produce video 12 videos to conference server.
then run parallel load test server size 48 core and run selenium web driver browser to join room and create consume (12 consumer per selenium web browser) . But some consumer slow create ( Second ) and some consume create ( millisecond )

If consumer is being created after piping then it will take more time than the normal consumer because of the pipetransport creation process. That may be the case.

When many join at the same time, some consumers take quite a long time to join (many seconds), but some take just milliseconds. Is there anyway I could improve the many seconds join time?. Without high concurrency of joins, there is no problem.@zaidiqbal

There must be something wrong in your app code. When you say ‘many’, how many do you mean? And when you say ‘many seconds’, how many seconds do you mean?

This is not about PipeTransports. This is about the normal flow when creating first Consumer in a browser since it requires creation and ICE connection of the WebRtcTransport between client and server.

Please check the “Client and server flows” documentation.

The first consume should take around 1,2 seconds? @pinyoo if it is that much time then no need to worry.

I was wrong. I meant that first Consumer requires an extra signaling from client to server to tell the latter about client’s DTLS settings.

1 Like

The screenshot seems to demonstrate the “fast” case, where all functions return in a matter of microsecond. Where is the other one? :slightly_smiling_face:

Nice catch, didn’t notice that, he may have forgotten to attach.

Sorry for my bad english. To clarify:

  1. 48 clients from 48-core machine. Each client joins to consume 6 videos at the same time. (288 consumes totally) Each client runs on separate browser process. I believe they don’t share any user/session information.
  2. many seconds means 3,4, and also 10+ seconds to join, attached the graph.
  3. The diagram on top of this page show just the case I tried. Some clients (having the same diagram join) fast (milliseconds), some clients join slow (10+ seconds)
  4. In slow case, I attached the log on top. It seems there are a lot of ReceiveRtpPacket() for one join.

All of the slow joins come from first consume of the client. In the graph, there are 8 out of 48 first consume that are slow, the rest are very fast.@zaidiqbal @ibc @snnz