thank you all for your replies, esp Gabriel and Anthony for your insightful answers. all processes (freeswitch, mysql, apache, vs..) running on the same machine. i think this is the major problem. now we are adding more hw to increase the number of fs boxes. but on the long run, we have to try what Anthony says. On Sat, Apr 14, 2012 at 7:02 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
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@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@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
_________________________________________________________________________ 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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ 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