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.
The screenshot seems to demonstrate the âfastâ case, where all functions return in a matter of microsecond. Where is the other one?
Nice catch, didnât notice that, he may have forgotten to attach.
Sorry for my bad english. To clarify:
- 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.
- many seconds means 3,4, and also 10+ seconds to join, attached the graph.
- 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)
- 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