On Mon, Jun 2, 2008 at 12:45 AM, Thomas Plotkowiak <plotti at gmx.net> wrote: > So over the weekend I performed a litle benchmark-test of the conference > bridge and am a bit puzzled with the results: > > I took the confbench.c code and just commented out the null-ports. > So what happens is it creates sine ports and mixes them in the conference > bridge. > I ran the same test with 1,2,4,8,16,32,64,128 and 256 Sineports, one time > with resampling and one time without. > My machine is a AMD 64 Dual Core 4600+ with 3gig RAM. > > What you see in the attached chart is, that with resampling with only 32 > ports the cpu usage is already 100% and without resampling with 250 > Sineports the CPU Usage is only 20%. > Thanks for the nice chart! It's very useful. > Does that mean that: > > with resampling you practically can't have conferences with more than 32 > people The default algorithm for resampling uses the high quality with large filter and this requires lots of computation indeed. You can try to use small filter or linear resampling with PJMEDIA_CONF_SMALL_FILTER or PJMEDIA_CONF_USE_LINEAR flag when creating the conference bridge. > without resampling (when you extrapolate) you cant have conferences more > than around 1000 people? > How did you come to this conclusion? There's no hard limit on the number of participants in the bridge, so it's only limited by the processing power of the CPU (it may or may not exceed 1000). > What do you think of this conclusion: > > If you take decoding, encoding the signal and all the other stuff into > account, the limit of Conference-Servers must be somewhere less then 1000 > participants in one conference, because they are limited by the > computational power and not the available bandwidth? Yeah probably something like that. But I don't think people will want to join to a conference with more than tens people, so if a conference server needs to accommodate large number of people, I think creating multiple bridges (and hence multiple/separate conferences) probably is better. This approach is also more scalable since you can then run the bridges on different threads. Cheers Benny
