[Freeswitch-users] dynamic dialplan alternatives

[Anthony Minessale]

If you really want the fastest dialplan possible, write a new dialplan
module in C.
You only have to implement 1 function, a dialplan hunt function that
gets data from the session and builds and returns an extension object
which is basically just a list of app/args.  You can glue in any other
stuff you want from there.

The dialplan implementations we carry in tree tend to offer a blended
balance of performance and flexibility/extensibility to serve as both
a demo and a practical on-ramp.





On Sat, Apr 14, 2012 at 10:51 AM, Anita Hall <anita.hall at simmortel.com> wrote:
> Could he use mod_odbc_query instead of xml curl to directly get his dialplan
> from a DB, thus removing the webserver from the picture altogether. I have
> not tried this but it looks better or am I missing something ?
>
> http://wiki.freeswitch.org/wiki/Mod_odbc_query
>
> regards,
> Anita
>
>
>
>
> On Fri, Apr 13, 2012 at 10:52 PM, Gabriel Gunderson <gabe at gundy.org> wrote:
>>
>> On Fri, Apr 13, 2012 at 6:37 AM, huseyin kalyoncu <hkalyoncu at gmail.com>
>> wrote:
>> > we are currently have two fs boxes load balanced by osips.
>> > in each fs we have dynamic dialplan with mod_xml_curl using php & apache
>> > &
>> > mysql. this conf is doing just fine with current load (about 20 cps) but
>> > with the
>> > increasing of incoming traffic, it shows some performance issues.
>> > we want to increase our call throughput.
>>
>> You don't really give us enough to go on. A few questions that I have
>> when I read this...
>>
>> * Are the DB and HTTP servers running on stand alone servers, or are
>> they running on the FS server?
>> * What kind of hardware are they each running on? RAM, CPU, disks?
>> * What kind of load do the servers have when you see performance issues?
>> * What have you done to optimize your web stack (other HTTP servers
>> etc)? Are you caching where you can?
>> * Have you analyzed your SQL to find any slow queries?
>>
>> Now, I don't expect you to answer all of these in this email thread,
>> but I'll bet if you reviewed them, you'd be able to bump your
>> performance without having to revisit your current approach.
>>
>>
>> > i searched through fs site and mailing list and came up with following
>> > options:
>>
>> I'll comment on this generically, but I can't really say what each
>> approach will (or will not) do for your current situation.
>>
>>
>> > 1) using lua or (python?) to serve dialplan instead of mod_xml_curl
>>
>> This works. Lua is lighter so it may give you better performance than
>> Python (this is a non-issue if you're using Python in a long-living
>> process with event socket or mod_xml_curl). Regardless of languages,
>> this approach has a drawback in that processing is done on the same
>> server that's running FreeSWITCH.
>>
>>
>> > 2) writing a dialplan module (something like mod_xml_curl) in c which
>> > will do
>> > all the db lookups etc..
>>
>> That seems a little extreme. Many people have scaled way up without
>> resorting to that approach.
>>
>>
>> > 3) using mod_erlang_event in outbound mode & spawning several erlang
>> > workers to do db lookups etc..
>>
>> This is about the same as #4 (give or take some Erlang magic).
>>
>>
>> > 4) using mod_event_socket in outbound mode & making db lookups on a
>> > different server.
>>
>> This is a fine approach when controlling the call, but you still need
>> some basic dialplan to get the calls going where they need to go. I
>> don't see it as the right way to solve your scaling problem, but it
>> might be part of the overall solution.
>>
>>
>> It sounds like you might be giving up on mod_xml_curl too soon.
>> Scaling HTTP is a well known problem with lots of tools available to
>> help you. When developing for mod_xml_curl, try returning the simplest
>> bit of dialplan you can and do all the work (logic, DB, etc.) on the
>> HTTP server. And don't forget that in *any* scaling scenario, you will
>> need to bring hardware, *real* hardware :)
>>
>> Good luck and let us know how you end up solving the problem.
>>
>>
>> Best,
>> Gabe
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> 
>> 
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at 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 at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>



-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale at hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
googletalk:conf+888 at conference.freeswitch.org
pstn:+19193869900