[Freeswitch-dev] mod_event_socket or mod_xml_rpc?

Thu Jan 16 04:56:03 MSK 2014

I use the erlang way, but I played some of the ESL while I'm writing a book about FreeSWITCH, and I did even write a subset of a pure ruby version of ESL since it's not easy to get the swigged version work on Mac in the old days, so I know the detail of the ESL protocol and challenge of write a new ESL implementation.

But it's true that nearly all lang has a none-swig ESL. One reason I think maybe because some language has async or other versions of socket implementation that is not compatible to the swigged-ESL. e.g. gevent in Python, event machine in ruby, Netty for Java etc.

I had briefly tested the ESL performance before, looks like the mod_event_socket version has some bottle necks since the erlang dispatcher mechanism which use a fair dispatching model and the socket is controlled by a single erlang process that has some bottle necks on load which causes lost events. The mod_kazoo version improved that by start a new raw socket along side the socket between the erlang nodes, and more over it can add filter to events to filter out unused header, so it performs better. I also made a patch for mod_kazoo that replaced the for-i-in-all-headers loop to a hash based compare and it got some performance improvement.

I also compares with the C ESL, by manually generate a large number of events that has 1000+ headers (normal events would have 100+ and a typical CHANNEL_HANGUP_COMPLETE might be around 500 I don't remember exactly), looks like the bottleneck is at the ESL client which must decode all the headers from plain text to a linked list. But I'm not 100% sure since on the FS side it has to serialize 1000 headers from a linked list to string. So if we can use a binary body to avoid the serialization/deserialization it might help get better performance, but since the event is linked list it might need serialize anyway.

But for sure you only can get the bottle neck if you are runing pressure test or with very busy traffic, and ESL is better for performance. xml_rpc based on an old version of abyss (the new version is not open now) and if has new lib we can use I'm happy to replace that. btw, I extended xml_rpc to support websocket and it's been used in FreeSWITCH-Portal.

On Thursday, January 16, 2014 at 8:37 AM, João Mesquita wrote:

> Tony, the swigged version of ESL python module is not at all pythonic. As an example the use of get header for events that could use a more pythonic syntax like dicts do. I didn't mean to say that I wanted to no use the ESL C implementation as base at all, I just meant that the wrapper could be done using a tool that would make the python module more pythonic but still keeping the underlying implementation in C intact. Maybe that is doable using swig an if that's the case please ignore my own stupidity.  
>  
> Sent from my iPhone
>  
> On Jan 15, 2014, at 9:30 PM, Anthony Minessale <anthony.minessale at gmail.com (mailto:anthony.minessale at gmail.com)> wrote:
>  
> > Why would you want to make a non-swig version of the ESL lib?  The whole point is to make sure you get a reliable client.
> > Everyone who tries to make their own runs into one of many challenges that are hard to overcome in a script lang.  This is why you have the benefit of the wrapped C lib.
> >  
> > xml_rpc has a bit less capability and is for sure less stable and scalable when put head to head with ESL.
> > I wrote both of them myself so I'm not driven by affinity to one or the other.  AFAIK xml_rpc is stable but the lib used is not so hot and I always wanted to use something better.
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> > On Wed, Jan 15, 2014 at 6:10 PM, canuck15 <canuck15 at hotmail.com (mailto:canuck15 at hotmail.com)> wrote:
> > > I sort of figured someone would say that.  Actually mod_xml_rpc seems to be similar to mod_xml_curl. Since I already have that mod_xml_curl fetches from my app  working well I don’t think I will switch that.  Also just read that fs_cli uses ESL so that has sold me on sticking with it.  I just want to make sure I am not using features that are a bit on the fringe where it’s not very active, well tested, and fixes don’t come along very often.  
> > >   
> > > From: freeswitch-dev-bounces at lists.freeswitch.org (mailto:freeswitch-dev-bounces at lists.freeswitch.org) [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of Michael Jerris
> > > Sent: Wednesday, January 15, 2014 11:17 AM
> > > To: freeswitch-dev at lists.freeswitch.org (mailto:freeswitch-dev at lists.freeswitch.org)
> > > Subject: Re: [Freeswitch-dev] mod_event_socket or mod_xml_rpc?  
> > >   
> > > They are completely different tools for different jobs, not a one or the other situation.
> > >   
> > > On Jan 15, 2014, at 1:32 PM, canuck15 <canuck15 at hotmail.com (mailto:canuck15 at hotmail.com)> wrote:
> > >  
> > >  
> > >  
> > > > I am trying to update an old abandoned app (WikiPBX) which is written using Django Python and uses mod_event_socket and mod_xml_curl to talk with Freeswitch.  
> > > >   
> > > >  
> > > > I’ve got most things working except the most important part which is mod_event_socket.  Now I found mod_xml_rpc which seems like a better way to go.
> > > >  
> > > >   
> > > >  
> > > > Just wanted to get some opinions which is the better api interface before I get too far into trying to get mod_even_socket working properly.  So far it’s been quite the headache.  I am currently looking at fusionpbx and bluebox code to see what they are doing.
> > > >  
> > > >  
> > >  
> > >  
> > >   
> > >  
> > >  
> > >  
> > >  
> > >  
> > >  
> > > _________________________________________________________________________
> > > Professional FreeSWITCH Consulting Services:
> > > consulting at freeswitch.org (mailto:consulting at freeswitch.org)
> > > http://www.freeswitchsolutions.com
> > >  
> > > 
> > > 
> > >  
> > > Official FreeSWITCH Sites
> > > http://www.freeswitch.org
> > > http://wiki.freeswitch.org
> > > http://www.cluecon.com
> > >  
> > > FreeSWITCH-dev mailing list
> > > FreeSWITCH-dev at lists.freeswitch.org (mailto:FreeSWITCH-dev at lists.freeswitch.org)
> > > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> > > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> > > http://www.freeswitch.org
> > >  
> >  
> >  
> >  
> > --  
> > Anthony Minessale II       ♬ @anthmfs  ♬ @FreeSWITCH  ♬
> >  
> > ☞ http://freeswitch.org/  ☞ http://cluecon.com/  ☞ http://twitter.com/FreeSWITCH  
> > ☞ irc.freenode.net (http://irc.freenode.net) #freeswitch ☞ http://freeswitch.org/g+
> >  
> > ClueCon Weekly Development Call  
> > ☎ sip:888 at conference.freeswitch.org (mailto:sip%3A888 at conference.freeswitch.org)  ☎ +19193869900  
> >  
> > _________________________________________________________________________
> > Professional FreeSWITCH Consulting Services:
> > consulting at freeswitch.org (mailto:consulting at freeswitch.org)
> > http://www.freeswitchsolutions.com
> >  
> > 
> > 
> >  
> > Official FreeSWITCH Sites
> > http://www.freeswitch.org
> > http://wiki.freeswitch.org
> > http://www.cluecon.com
> >  
> > FreeSWITCH-dev mailing list
> > FreeSWITCH-dev at lists.freeswitch.org (mailto:FreeSWITCH-dev at lists.freeswitch.org)
> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> > http://www.freeswitch.org
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org (mailto:consulting at freeswitch.org)
> http://www.freeswitchsolutions.com
>  
> 
> 
>  
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>  
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org (mailto:FreeSWITCH-dev at lists.freeswitch.org)
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>  
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20140116/9f71932f/attachment.html 