[Freeswitch-users] dynamic dialplan alternatives

[Anita Hall]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20120414/8df03564/attachment.html