Background
This was originally designed for my private use case (with my family only -max users about 4-), so currently uses mesh network for webrtc group calls and also limited max users to 9.
But this yeah doesn't make sense since each peer on client-side should take other 8 streams and maintain those connections which take up huge bandwidth.
But as it's been running on t2.micro(thanks free tier!) instance this could be the correct configuration in my current phase. Server takes up about half of the total CPU resources. (BTW Additional resources are required too as well) And for my case as I'm using blue/green deployment strategy(this might be BAD), resources might take up almost 2 times than its usual case. So, from the given conditions, it might be better idea to burden resource usages to client-side(this is BAD yeah I know).
Still, an inconsistency between the architecture and the network also arises. And this is the key reason why I suggest this. It might take much time to re-configure network and given current cpu usages except deploying(I could use other strategies) process don't take up much. Let's make use of the resources as possible as it could and reduce cpu usages and bandwidth from client-side.(yeah this is correct)
Suggestion
So, though resources might take a little bit let's give it a try for changing the connection method to SFU or MCU and see if the instance can stands.
Background
This was originally designed for my private use case (with my family only -max users about 4-), so currently uses mesh network for webrtc group calls and also limited max users to
9.But this yeah doesn't make sense since each peer on client-side should take other 8 streams and maintain those connections which take up huge bandwidth.
But as it's been running on t2.micro(thanks free tier!) instance this could be the correct configuration in my current phase. Server takes up about half of the total CPU resources. (BTW Additional resources are required too as well) And for my case as I'm using blue/green deployment strategy(this might be BAD), resources might take up almost 2 times than its usual case. So, from the given conditions, it might be better idea to burden resource usages to client-side(this is BAD yeah I know).
Still, an inconsistency between the architecture and the network also arises. And this is the key reason why I suggest this. It might take much time to re-configure network and given current cpu usages except deploying(I could use other strategies) process don't take up much. Let's make use of the resources as possible as it could and reduce cpu usages and bandwidth from client-side.(yeah this is correct)
Suggestion
So, though resources might take a little bit let's give it a try for changing the connection method to SFU or MCU and see if the instance can stands.