[Freeswitch-users] dynamic dialplan alternatives

[Gabriel Gunderson]

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