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@gundy.org> wrote:
On Fri, Apr 13, 2012 at 6:37 AM, huseyin kalyoncu <hkalyoncu@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@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