I have set ‘OPENVIDU_PRO_CLUSTER_LOAD_STRATEGY’ = sessions, but not able to understand what is number of session limit before picking the right Media Node to create the new session.
Let’s say i have 3 Media nodes and number of session on each media nodes are as below
Media Node 1 - 2 Sessions
Media Node 2 - 1 Session
Media Node 3 - 0 Session
It seems it works like picking the least loaded node which is Media Node 3 and will create next session on this. I am not able to handle the situations where i know my 1 Media node can’t handle more than 2 Concurrent sessions (Considering 1 Publisher and 100 subscribers in each session).
Can i fix the session limit per Media Node or what is best way to configure this parameters?
Is there any detailed documentation explaining how different load strategies work and how one can decide which strategy should be used.
Hi,
Currently in version 2.14.0 there is no way to limit the number of sessions that may be initialized in Media Nodes. The different load strategies will always allow initializing new sessions, they just decide in which Media Node should be placed. In future releases we plan to add a way in OpenVidu Pro of configuring specific expected loads for each Session. This way the algorithm (and the 2.15.0 autoscaling feature) will perfectly know how to properly distribute sessions in the existing Media Nodes.
But for you specific use case in which you know that each Media Node is only able to handle 2 sessions ata a time, it is really as simple as using OPENVIDU_PRO_CLUSTER_LOAD_STRATEGY=sessions, but making sure with OpenVidu Pro REST API that you have an empty Media Node (or a Media Node with only 1 session) where to initialize it before joining the first user. If not, you must launch a new Media Node.
Does that make sense?
Regards.
Thanks pabloFuente,
"In future releases we plan to add a way in OpenVidu Pro of configuring specific expected loads for each Session". Launching a new media node basis on expected load of session + 2.15 autoscaling feature will really help to reduce the headache to start and stop server based on our custom logic.
I will really appreciate if Openvidu team can distribute a session between several media nodes and scale session horizontally. If we could achieve this then It will make openVidu out of the box product.
Distributing a session between media nodes is in our roadmap.
But technically is complex, specially if the sessions grows over the time (because you can not distribute it in advance).
Ok, i dont know how but some of the Player are doing it like Origin Node and Edges node. It creates session on Origin Node and distribute the load across all available edges. When load grows over the time the Session Manager (In case of OpenVidu it’s Openvidu Pro server) create a new edges at run time, attach it with the origin and return the end URL to new joined subscriber.
It’s a kind of Master and Slave architecture where broadcaster is attached with Master(Origin server) and subscribers are attached with Slave (Edge server).
Thanks @rohit.roy,
We are thinking in an architecture like you described. But it is a bit more complex if you plan to have several concurrent sessions sharing the same media servers. If you plan to have only one session and you know it will be very big, you can prepare in advance.
If this feature is really important for your use case, you can support it as part as our commercial services.
Regards
Thanks @micael.gallego,
We are planning and trying to write some custom script which will up the Media server instances basis on our session strength and total active subscribers as of now. The only things which make me worry for the time being is…
-
On what capacity we should launch our Media server (Like if we launch with C5.2X large, can it handle 500 subscribers in 1:M topology)?
-
On what capacity we should launch our openVidu Pro server (If we have launched N number of Media server to support 5000 concurrent subscribers with Individual Recording mode, Considering max 500 subscribers on a single Media node. Can a single openVidu Pro server handle this (openVidu server with C5.2X large machine) or what should be the capacity of Pro Server?
If you guide us on the above two problem statements then we are good to go to solve our current use case.
We are designing an extensive load testing experiment to have detailed responses to such questions. We plan to have a report in 2 weeks.
Until then, you will have to test yourself.
Nice I’m waiting too .
I hope this will be publish in this release
Hi @micael.gallego, any update on report on load testing.
Meanwhile i did load testing (1 Publisher and all are subscribers) using Puppeteer and allowed joining subscribes in a browser. Actual video/stream was getting played on those browsers.
One Pro node server (c5.xlarge - 4 VCPU)
One Media node (c5.xlarge - 4 VCPU)
Basis on my load testing it seems
- Media node - No issue if load is between 250-300 subscribers. Keeping subscribers below 250 is really safe.
- Pro node - As per the pattern it seems pro node with 4 VCPU can handle around 1200 - 1500 concurrent connections. I have also enabled KIBANA on this PRO node.
Below are the summary of load testing
It would be really great if you can share your report too. I am looking for 3000 - 4000 concurrent connections across different sessions that’s why need to check what should be capacity for PRO NODE to handle 3000 - 4000 active users connections.
Hello @rohit.roy,
Thank you very much for sharing your performance results. We had to dedicate to other stuff and we haven’t yet started with our complete load testing.
Using a more powerful master node you will be able to manage 3000 - 4000 concurrent participants.
It is in our roadmap to support highly available master nodes so you dynamically add or remove master nodes. But it won’t be available until the end of the year.
Regards
Hello @rohit.roy We have tried similar testing but with more publishers and are facing an issue where we are hitting the CPU max much earlier.
Have you tried load testing in a case of many-to-many?
Regards
Hello @Venkatesh_N No i didn’t try M:M topology. I have 1:M requirement and i prepared the script based on my use case. One more thing, i have limited the bandwidth in my case which is “256 kbps max” and no issue with AV at subscriber side. Also didn’t find any glitch in Recording so far.
Please share you report if possible.
It’s obviously it will take more CPU.
M:M typology needs m*m streams.
Instead 1:M needs only M streams.
So that’s why its need more cpu
Hi Rohit… Can you share your contact information… Would like to have a quick call on the CPU utilization and bandwidth usage.