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
>