Whatâs your bandwidth though? The bandwidth is more important for the problem youâre reporting. Although, if youâre having the same issues on meet.jit.si, then this could be a totally different problem.
Shared Cpu is not very good. Iâd prefer 2 full Cpu over 4 shared ones. There is the ânoisy neighbourâ problem. For a real time system, it may be an issue.
Edit: while Iâm at it, there is also the possible problem of bad bandwidth (typically wifi) client side.
No, the clientâs wifi stability will always affect their video-conferencing experience. If a client has bandwidth thatâs obviously struggling, you can tell them to lower their video quality (using the âManage video qualityâ setting), that way, the lower bandwidth requirement will help to smoothen their meeting experience.
Got you Freddie,âŚwe aim to serve 1000 customers- using jitsi in our system, we are marketplace so it will be 1 user professionals to 100 customer for example, and in same moment 10 or more user professionals can be having streaming,too. So I guess the combination :
JMS General Purpose 4vCPUs 16GB RAM
JVB CPU-Optimized 4vCPUs 8GB RAM
âŚshould be a good start for offering stable and quality experience right? Or is there smth else you would suggest to what out on?
Youâll need roughly around 10 JVBs to host 1000 concurrent users, if those users are going to be joining the meeting on Jitsi. However, if by âstreamingâ, you mean livestreaming to the customers, then one JVB will do. You will of course need 10 Jibri instances to stream.
I meanâŚin one room we can have up to 100-150 people and all together in all rooms 1000 people, as we serve teacher professionals who have their own weibnars - so by streaming, probably wrong wording, webianr is better - where customers can also turn on the camera⌠.so I guest this is the 10 JVBs case⌠and what about kubernetas? do you have some experience with it please for these cases?