Our Stasis App uses ARI bridging to create voice conferences. As more participants are added, we see heavy CPU usage during mute/unmute operations. With 60 participants in a conference, TOP shows 90%+ (and sometimes over 100%). CPU loading does fall afterwards, but unpredictably - so the loading can remain uncomfortably high after such an operation.
It would be helpful to know a couple of things about the way the bridging is implemented on the processor
Are we skirting disaster here, or is this a normal pattern for garbage collection? Can we assume that we are operating within safe levels, and resources will be released on demand?
Presumably each bridge must run on a single thread. If we increase the processor speed will this help us? Will adding a voice compression card help us? Would it be sensible to break each conference into sub-conferences, so that several ‘child’ bridges each have an originated call to a ‘master’ bridge (we’d have more co-ordination code, but it seems possible)?