VoIP Mailing List Archives

[brian at freeswitch.org]

The script has a javascript interpreter allocated sitting there eating up ram for no reason... so to scale better its wise to exit the script and do your conference.

Lua is lighter weight but still having the interpreter hang around when not needed isn't wise.


/b

On May 14, 2009, at 11:32 AM, Mike Fedyk wrote:

[stevecrozz at gmail.com]

I keep hearing that lua is lighter weight / more scalable than javascript. I'd love to see some data that shows how big the difference really is. I could port all my scripts from javascript to lua, but it would require a lot of overhead (me learning lua + actually porting the scripts). I want to know how much benefit there really is to that.

--Stephen

On Thu, May 14, 2009 at 10:01 AM, Brian West <brian@freeswitch.org (brian@freeswitch.org)> wrote:

[brian at freeswitch.org]

Its obvious if you look at the size of the JS VM vs the lua VM.. it would clearly scale better not needing megs and megs of ram per call vs about 160kb for lua. Lua took about 20 min to learn and about an hour to get the finer points down.

/b


On May 14, 2009, at 12:24 PM, Stephen Crosby wrote:

[niall.crosby at gmail.com]

How would using the mod_event_socket compare to lua / javascript with
regards performance and scaling? (ignoring the client side of the
socket, just the Freeswitch side). Is there any performance issues to
placing a call into conference using with callflow from the
mod_socket?

N.

2009/5/14 Brian West <brian@freeswitch.org>:

[stevecrozz at gmail.com]

I think its less obvious to a user who'd never heard of lua until recently. I think it would be very helpful if someone had a comparison and could put it on the wiki.

I spent some time poking around on the wiki before I decided to write my scripts in javascript. If I had seen any warnings on scalability/performance, especially with good data to back it up, I probably would have chosen something else.

--Stephen

On Thu, May 14, 2009 at 10:31 AM, Brian West <brian@freeswitch.org (brian@freeswitch.org)> wrote:

[pete at privateconnect...]

I will further confirm Brian's statement. I originally started writing scripts in JS because I was more familar with it. I ran into several problem with scalability and threading issue that prompted me to look at LUA.

LUA took less than a day to get a basic understand and an additional few hours to understand their version of objects. I had migrated all 15 of my JS scripts into functioning LUA script within 5 hours. Including re-creating the object-oriented nature of my JS source.

LUA consumes far less resources and begins execution faster than JS. The only thing I need JS for at this time is cURL-like calls, as the built-in LUA has no equivalent to the JS Socket object. Having said that, the built in LUA can take advantage of LUA libraries that are installed on the OS, and LUA socket libraries do exists, so it is just a matter of me getting the time to install them.

One more handy benefit for LUA, you can configure LUA scripts to run at switch startup to perform tasks (like a cron system) within the switch core.

-pete

[stevecrozz at gmail.com]

Thanks Pete,

I've been hanging out on #freeswitch and I started a conversation on this topic. User 'mercutioviz' created this wiki page mercutioviz: http://wiki.freeswitch.org/wiki/Which_scripting_language_should_I_use%3F

which should help new freeswitchers not make the mistake we made and have to rewrite everything. If you have anything to add to this, it would be appreciated I'm sure.

--Stephen

On Thu, May 14, 2009 at 2:22 PM, <pete@privateconnect.com (pete@privateconnect.com)> wrote:

[dave at 3c.co.uk]

On Thu, 2009-05-14 at 12:31 -0500, Brian West wrote:

[anthony.minessale at g...]

Unfortunately, no scripting language we have encountered
has ever done proper threading to the point that you could even begin to do that.

Lua is one of the better ones in a threaded env only because they solved the problem by making a tiny VM that
can be easily reproduced thousands of times.  You still can't share a lua vm across threads or it will crash because they
use lots of setjmp longjmp calls to travel between their virtual stack and the real one.

As a matter of fact, spidermonkey has code that tries to be threadsafe (but you have to enable it, --with-threadsafe makes me nervous =]) and it shares as much as it can already and we have debated changing it so it creates a whole
JS instance per call just because of all the garbage collection and thread safety issues we have encountered.
you have to call a whole bunch of hidden mutexes marked suspend and resume etc everywhere in the code where you
transition from executing script side code to a blocking FreeSWITCH function.


Really, the only point in my original comment was that if you want to scale up something that uses scripting the first way to save
resources is to not leave the script open while you do something you know will take a long time "playing a 2 hour file, bridging a call, joining a conference" because the script resources are allocated and doing nothing this whole time and they all share a global garbage collector.  if you don't need to remain in the script just transfer the call to a static extension and close it.  It's just a suggestion really.



On Thu, May 14, 2009 at 4:56 PM, David Knell <dave@3c.co.uk (dave@3c.co.uk)> wrote: