http://wiki.freeswitch.org/wiki/Performance_testing_and_configurationslists some performance bottlenecks, I'd like to check if they are still an issue... I recall some changes in how threads are run. 1) "libsofia only handles 1 thread per profile, so if that is your bottle neck use more profiles" Is this still true? I saw Anthony mention in a ML post that there is a param for a separate thread for incoming registrations but I can't find it on the wiki or find the email. 2) "Reports of running more than a single instance of FreeSWITCH has helped." If libsofia doesn't have a bottleneck (see #1), then what part of FS would? Each call get it's own thread. Why would this help? 3) "On a normal configuration, core.db is written to disk almost every second, generating hundreds of block-writes per second. To avoid this problem, turn /usr/local/freeswitch/db into an in-memory filesystem." It seems the other alternative is: "-nosql -- disable internal sql scoreboard" What does -nosql disable? e.g. for a dialer trunk you don't need presence, track-calls.. can you still get an active call count from FS? 4) from here<http://wiki.freeswitch.org/wiki/Switch.conf.xml#initial-event-threads> "initial-event-threads Number of event dispatch threads to allocate in the core. Default is 1. If you see the WARNING "Create additional event dispatch thread" on a heavily loaded server, you could increase the number of threads to prevent the system from falling behind." If I expect high cps/load, e.g. for dialer term, should I set this higher from the start? Anything else I should know, other than "FreeSWITCH is free, so you can use that money you saved to get good hardware" ? I remembered that part! -Avi Marcus BestFone
A few answers inline. William King Senior Engineer Quentus Technologies, INC 1037 NE 65th St Suite 273 Seattle, WA 98115 Main: (877) 211-9337 Office: (206) 388-4772 Cell: (253) 686-5518 william.king@quentustech.com On 03/09/2013 10:30 AM, Avi Marcus wrote:
http://wiki.freeswitch.org/wiki/Performance_testing_and_configurations lists some performance bottlenecks, I'd like to check if they are still an issue... I recall some changes in how threads are run.
1) "libsofia only handles 1 thread per profile, so if that is your bottle neck use more profiles" Is this still true? I saw Anthony mention in a ML post that there is a param for a separate thread for incoming registrations but I can't find it on the wiki or find the email. The param you are looking for is inbound-reg-in-new-thread, though there was at least one other improvements over the last year to reduce this bottleneck. Checking the git logs for the mod_sofia directory should show a few.
2) "Reports of running more than a single instance of FreeSWITCH has helped." If libsofia doesn't have a bottleneck (see #1), then what part of FS would? Each call get it's own thread. Why would this help? This helps so that no one call is blocking any other call. Basically FS can keep doing productive call processing for as long as there is a call on the box that is ready.
3) "On a normal configuration, core.db is written to disk almost every second, generating hundreds of block-writes per second. To avoid this problem, turn /usr/local/freeswitch/db into an in-memory filesystem." It seems the other alternative is: "-nosql -- disable internal sql scoreboard"
What does -nosql disable? e.g. for a dialer trunk you don't need presence, track-calls.. can you still get an active call count from FS? Seems pretty simple to test.
4) from here <http://wiki.freeswitch.org/wiki/Switch.conf.xml#initial-event-threads> "initial-event-threads Number of event dispatch threads to allocate in the core. Default is 1. If you see the WARNING "Create additional event dispatch thread" on a heavily loaded server, you could increase the number of threads to prevent the system from falling behind."
If I expect high cps/load, e.g. for dialer term, should I set this higher from the start? Setting this between 1 and the number of cores on the box would be your options. Basically what happens is when an event is fired in FS it is pushed into a queue to be processed. FS will give you that log line if the event system start to get backed up(and at this point is where it starts a new eventing thread). I'd say grep your logs to see if you are running into an issue, and if so then up the number. If you've reached the point where you have started 1 thread per core on your box, and you are still hitting this, then your bottleneck is event subscriptions. Check to see if you have a module that is inefficiently handling events.
Anything else I should know, other than "FreeSWITCH is free, so you can use that money you saved to get good hardware" ? I remembered that part!
-Avi Marcus BestFone
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
1) "libsofia only handles 1 thread per profile, so if that is your bottle neck use more profiles" Is this still true?
This is still true.
3) "On a normal configuration, core.db is written to disk almost every second, generating hundreds of block-writes per second. To avoid this problem, turn /usr/local/freeswitch/db into an in-memory filesystem." It seems the other alternative is: "-nosql -- disable internal sql scoreboard"
What does -nosql disable? e.g. for a dialer trunk you don't need presence, track-calls.. can you still get an active call count from FS?
You'll also lose commands like 'show calls' and 'show channels'. Possibly some registration information too, since that's stored in the core DB too. I forget whether -nosql disables just the core DB or the sofia DB etc too (I never use it). As well as using a ramdisk, using ODBC can help too - the proper databases are far better geared to scaling/concurrency than SQLite which is more for small-scale/embedded systems. It can also offload the database load onto an entirely separate server.
See comment below. Sent from my iPhone On Mar 9, 2013, at 2:12 PM, Steven Ayre <steveayre@gmail.com> wrote:
1) "libsofia only handles 1 thread per profile, so if that is your bottle neck use more profiles" Is this still true?
This is still true.
I think William is correct on this. I saw something on the mailing list that this limitation was fixed in Sofia. I'll take a look at some logs and see for sure. - BDF
3) "On a normal configuration, core.db is written to disk almost every second, generating hundreds of block-writes per second. To avoid this problem, turn /usr/local/freeswitch/db into an in-memory filesystem." It seems the other alternative is: "-nosql -- disable internal sql scoreboard"
What does -nosql disable? e.g. for a dialer trunk you don't need presence, track-calls.. can you still get an active call count from FS?
You'll also lose commands like 'show calls' and 'show channels'. Possibly some registration information too, since that's stored in the core DB too. I forget whether -nosql disables just the core DB or the sofia DB etc too (I never use it).
As well as using a ramdisk, using ODBC can help too - the proper databases are far better geared to scaling/concurrency than SQLite which is more for small-scale/embedded systems. It can also offload the database load onto an entirely separate server.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
This may be relevant http://freeswitch-users.2379917.n2.nabble.com/Running-multiple-SIP-profiles-... This is still true. What may be better to say is that the sofia profile is still single-threaded and may still become a bottleneck, but it'll perform much better now than it used to (when the wiki page was written). -Steve On 9 March 2013 20:18, Brian Foster <bdfoster@endigotech.com> wrote:
See comment below.
Sent from my iPhone
On Mar 9, 2013, at 2:12 PM, Steven Ayre <steveayre@gmail.com> wrote:
1) "libsofia only handles 1 thread per profile, so if that is your bottle
neck use more profiles" Is this still true?
This is still true.
I think William is correct on this. I saw something on the mailing list that this limitation was fixed in Sofia. I'll take a look at some logs and see for sure.
- BDF
3) "On a normal configuration, core.db is written to disk almost every second, generating hundreds of block-writes per second. To avoid this problem, turn /usr/local/freeswitch/db into an in-memory filesystem." It seems the other alternative is: "-nosql -- disable internal sql scoreboard"
What does -nosql disable? e.g. for a dialer trunk you don't need presence, track-calls.. can you still get an active call count from FS?
You'll also lose commands like 'show calls' and 'show channels'. Possibly some registration information too, since that's stored in the core DB too. I forget whether -nosql disables just the core DB or the sofia DB etc too (I never use it).
As well as using a ramdisk, using ODBC can help too - the proper databases are far better geared to scaling/concurrency than SQLite which is more for small-scale/embedded systems. It can also offload the database load onto an entirely separate server.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (4)
-
Avi Marcus
-
Brian Foster
-
Steven Ayre
-
William King