Our xml parser is very low on memory because its a small barebones lib based on c pointer black magic that we came across. Scary to look at but fast and low in memory usage.

Our onboard asr and tts is only as bad in resource consumption as the engine you choose, but we do have mrcp.

The big one, as you have already identified, is the javascript lib.  The one we have does not scale along with FS for sure.  However, that is when using the js context to run the whole call.  Maybe in the case of vxml it would be a different model?  Lua has shown the best parallel scalibility of all the embedded languages because its small and runs a separate interpreter for each instance.  If we found a js implementation that works in a similar way it might scale.

On Jul 10, 2010 7:56 AM, "Jan Berger" <jan.berger@video24.no> wrote:

 

I don’t use OpenVXI for reasons like – dead project, performance, reliability, non-scaling architecture, wrong dependencies – and so on. We have a target of 20,000 sessions on my laptop alone – and I have already secured that and more. We can do more, but we start running out of memory. What I expect out of FreeSWITCH/CCXML/VXML is that we can scale up as much as FreeSWITCH can without CCXML/VXML being the show-stopper.

 

Then OpenVXI came out it was adopted by tier1 companies that still use the stack today. Some people consider that a reference, but they fail to understand that those companies have the strength needed to pick up half-done-work and make it right. Though the ones I know of still struggle with performance issues.

 

<snip>

 

So when it was first invented, people tried to sell the editors for money, the only implementation...

</snip>

_______________________________________________
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