What happened when you created several thousand bridged channels as opposed to 2-person conferences? Just curious to see where your upper limits came in to play there.<div>-MC<br><br><div class="gmail_quote">On Sun, Aug 22, 2010 at 7:05 PM, Seven Du <span dir="ltr"><<a href="mailto:dujinfang@gmail.com">dujinfang@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Talked with brian, he thought the there might not much difference<br>
between them and suggest a perf test by me.<br>
<br>
I test on my Mac 10.6.4 64bit. First I increased cps to 100 and<br>
max-sessions to 8000. It seems that it cannot create more than 2560<br>
sessions on Mac, and I don't know how to increase the limit so I just<br>
use small numbers.<br>
<br>
The following ruby code create channels through ESL slowly. 30 * 10 *<br>
2 means 600 channels, and because I used loopback, it actually use<br>
1200 channels.<br>
<br>
bridge:<br>
1200 threads.<br>
300-400% cpu. (on Activity monitor) and load avg 600-800 (on top).<br>
Memory 300M.<br>
<br>
conf:<br>
2100 threads.<br>
300-400%cpu, load avg 600-800, or can be 39-1000(dosen't make sense?)<br>
memory 500M.<br>
<br>
<br>
<br>
<br>
<br>
30.times do |i|<br>
puts i * 10<br>
10.times do |j|<br>
if ARGV[0].nil? #bridge<br>
conn.bgapi("originate", "loopback/9664 &bridge(loopback/9664)")<br>
else #conference<br>
conf = "c#{i* 10 + j}@default"<br>
conn.bgapi("originate", "loopback/9664 &conference(#{conf})")<br>
conn.bgapi("originate", "loopback/9664 &conference(#{conf})")<br>
end<br>
end<br>
<br>
sleep 1<br>
end<br>
<br>
<br>
<br>
when I double the channels( 30 * 20 = i * j), ESL stuck when threads<br>
up to 2560 and it throws "cannot create channels". But, when I run<br>
"hupall" in FS, it start creating channels again. Don't know why FS on<br>
Mac has a 2560 threads limit.<br>
<br>
And after "hupall" again, there are dead channels(9 channels and 9 threads):<br>
<br>
4d5a2408-eaf6-4f3a-a401-7a916b1911f1,outbound,2010-08-23<br>
09:52:35,1282528355,loopback/9664-a,CS_EXECUTE,,0000000000,,9664,conference,c193@default,xml,default,L16,8000,L16,8000,,seven-macpro.local,,,HANGUP,,,,ffc4367e-bcde-43a5-a95e-e0fd5c4069ea<br>
f93fa824-a6ae-47ca-ae9c-ff6b8948df4f,outbound,2010-08-23<br>
09:52:35,1282528355,loopback/9664-a,CS_EXECUTE,,0000000000,,9664,conference,c194@default,xml,default,L16,8000,L16,8000,,seven-macpro.local,,,HANGUP,,,,4c8b1826-5afa-43ad-a73b-59a8c5d8f41c<br>
7611288b-be9e-4f70-9880-3919de567222,inbound,2010-08-23<br>
09:52:35,1282528355,loopback/9664-b,CS_REPORTING,,0000000000,,9664,playback,local_stream://moh,xml,default,L16,8000,L16,8000,,seven-macpro.local,,,HANGUP,,,,<br>
9142d487-f0b5-4636-a2eb-a0adaee19634,inbound,2010-08-23<br>
09:52:35,1282528355,loopback/9664-b,CS_REPORTING,,0000000000,,9664,playback,local_stream://moh,xml,default,L16,8000,L16,8000,,seven-macpro.local,,,HANGUP,,,,<br>
0d8bc340-edf7-4461-b1b4-91056c68474b,outbound,2010-08-23<br>
09:52:35,1282528355,loopback/9664-a,CS_NEW,,,,,,,,,L16,8000,L16,8000,,seven-macpro.local,,,HANGUP,,,,a9a8369e-f509-4b39-b689-8e616d29d5c3<br>
ed93c3d5-6780-4e75-bf48-6e326274be04,outbound,2010-08-23<br>
09:52:35,1282528355,loopback/9664-a,CS_NEW,,,,,,,,,L16,8000,L16,8000,,seven-macpro.local,,,HANGUP,,,,e321a328-0b7c-4f74-9af5-a5e3f083ff8a<br>
62aabb4b-4bfc-4ba0-a87c-2e1a76323cce,outbound,2010-08-23<br>
09:52:39,1282528359,loopback/9664-a,CS_EXECUTE,,0000000000,,9664,conference,c200@default,xml,default,L16,8000,L16,8000,,seven-macpro.local,,,HANGUP,,,,3a86d88d-33b2-42b2-a57c-e2cb2c1ec486<br>
b13c3e9d-7fb8-46f2-90c9-04a0ec770a2e,inbound,2010-08-23<br>
09:52:39,1282528359,loopback/9664-b,CS_REPORTING,,0000000000,,9664,playback,local_stream://moh,xml,default,L16,8000,L16,8000,,seven-macpro.local,,,HANGUP,,,,<br>
b8bb7b64-c57c-4c8f-9264-09eecf4aef57,outbound,2010-08-23<br>
09:52:39,1282528359,loopback/9664-a,CS_NEW,,,,,,,,,L16,8000,L16,8000,,seven-macpro.local,,,HANGUP,,,,e50d768b-37b8-4cfb-ab46-60e7ac029c83<br>
<br>
<br>
I also tested on a Linux server. It performs better. no detail data<br>
collected though.<br>
<br>
And, interesting, when I run a 30 * 20 bridge + 30 * 20 conference,<br>
loadavg suddenly grew to 2000+. But I can still run a "hupall" in<br>
fs_cli with so high load.<br>
<br>
Note:<br>
1) loopback might not typical in test.<br>
2) This is not a FS performance test, I only want the conclusion that<br>
2-way conference uses more resource than bridged calls.<br>
<div><div></div><div class="h5"><br>
On Thu, Aug 19, 2010 at 8:31 AM, Seven Du <<a href="mailto:dujinfang@gmail.com">dujinfang@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> Can someone explain the performance difference between bridged calls<br>
> and 2-party conference? or just in the code point of view?<br>
><br>
> Since in some scenarios third party may join into a bridged call, so<br>
> we need to transfer a bridged call into a conference first. Make a<br>
> conference anyway event for 2-parties will make logic simpler and<br>
> clear.<br>
><br>
> Thanks.<br>
><br>
> --<br>
> Blog: <a href="http://www.dujinfang.com" target="_blank">http://www.dujinfang.com</a><br>
> Proj: <a href="http://www.freeswitch.org.cn" target="_blank">http://www.freeswitch.org.cn</a><br>
><br>
<br>
<br>
<br>
--<br>
Blog: <a href="http://www.dujinfang.com" target="_blank">http://www.dujinfang.com</a><br>
Proj: <a href="http://www.freeswitch.org.cn" target="_blank">http://www.freeswitch.org.cn</a><br>
<br>
_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br></div>