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 ?<br><br>
<a href="http://wiki.freeswitch.org/wiki/Mod_odbc_query">http://wiki.freeswitch.org/wiki/Mod_odbc_query</a><br><br clear="all">regards,<br>Anita<br><br>
<br><br><div class="gmail_quote">On Fri, Apr 13, 2012 at 10:52 PM, Gabriel Gunderson <span dir="ltr"><<a href="mailto:gabe@gundy.org">gabe@gundy.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Fri, Apr 13, 2012 at 6:37 AM, huseyin kalyoncu <<a href="mailto:hkalyoncu@gmail.com">hkalyoncu@gmail.com</a>> wrote:<br>
> we are currently have two fs boxes load balanced by osips.<br>
> in each fs we have dynamic dialplan with mod_xml_curl using php & apache &<br>
> mysql. this conf is doing just fine with current load (about 20 cps) but with the<br>
> increasing of incoming traffic, it shows some performance issues.<br>
> we want to increase our call throughput.<br>
<br>
</div>You don't really give us enough to go on. A few questions that I have<br>
when I read this...<br>
<br>
* Are the DB and HTTP servers running on stand alone servers, or are<br>
they running on the FS server?<br>
* What kind of hardware are they each running on? RAM, CPU, disks?<br>
* What kind of load do the servers have when you see performance issues?<br>
* What have you done to optimize your web stack (other HTTP servers<br>
etc)? Are you caching where you can?<br>
* Have you analyzed your SQL to find any slow queries?<br>
<br>
Now, I don't expect you to answer all of these in this email thread,<br>
but I'll bet if you reviewed them, you'd be able to bump your<br>
performance without having to revisit your current approach.<br>
<div class="im"><br>
<br>
> i searched through fs site and mailing list and came up with following<br>
> options:<br>
<br>
</div>I'll comment on this generically, but I can't really say what each<br>
approach will (or will not) do for your current situation.<br>
<br>
<br>
> 1) using lua or (python?) to serve dialplan instead of mod_xml_curl<br>
<br>
This works. Lua is lighter so it may give you better performance than<br>
Python (this is a non-issue if you're using Python in a long-living<br>
process with event socket or mod_xml_curl). Regardless of languages,<br>
this approach has a drawback in that processing is done on the same<br>
server that's running FreeSWITCH.<br>
<br>
<br>
> 2) writing a dialplan module (something like mod_xml_curl) in c which will do<br>
<div class="im">> all the db lookups etc..<br>
<br>
</div>That seems a little extreme. Many people have scaled way up without<br>
resorting to that approach.<br>
<div class="im"><br>
<br>
> 3) using mod_erlang_event in outbound mode & spawning several erlang<br>
> workers to do db lookups etc..<br>
<br>
</div>This is about the same as #4 (give or take some Erlang magic).<br>
<div class="im"><br>
<br>
> 4) using mod_event_socket in outbound mode & making db lookups on a<br>
> different server.<br>
<br>
</div>This is a fine approach when controlling the call, but you still need<br>
some basic dialplan to get the calls going where they need to go. I<br>
don't see it as the right way to solve your scaling problem, but it<br>
might be part of the overall solution.<br>
<br>
<br>
It sounds like you might be giving up on mod_xml_curl too soon.<br>
Scaling HTTP is a well known problem with lots of tools available to<br>
help you. When developing for mod_xml_curl, try returning the simplest<br>
bit of dialplan you can and do all the work (logic, DB, etc.) on the<br>
HTTP server. And don't forget that in *any* scaling scenario, you will<br>
need to bring hardware, *real* hardware :)<br>
<br>
Good luck and let us know how you end up solving the problem.<br>
<br>
<br>
Best,<br>
Gabe<br>
<div class="HOEnZb"><div class="h5"><br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br>