On 11/13/09 6:58 PM, Eliot Gable wrote: Hi Eliot!
Performance is not an issue. I clocked 300 calls per second on such a setup using a Dell R710 with two XEON X5570s and 32 GB RAM as the FreeSWITCH server and a Dell 2950 4-core system with 8 GB RAM as the app server. The app server was at 15% - 20% idle at that rate and the
Haha, that should do the trick for me. Sounds realy good. I still prefer to use the internal ENUM system for all lookups, but if that's not possible then the mod_xml_curl method is the one for me I think. That takes all routing complexity away from the FS system.
meant that I could only pull 160 calls per second, even though the app server was 55% - 60% idle at that rate, because the ODBC call took 1/160th of a second to complete and all the requests were serialized.
OK, that's a problem. On the other hand 160 cps is still very good. If I keep an eye on where I use the limit app, it'll be OK.
are storing / querying your data from your database system. Actually, I suppose you could just be a bad programmer and end up making it exponential, but I'm assuming you know how to write code and design your database in a way that avoids that.
There's people in my department that know a few things about that, so I can always let my design get approved by them. :)
I have been considering writing a hash cache for the XML dialplan so that lookups can become constant time, but I have no idea when or if I will find the time to do that. :)
I know the feeling, working on three things at the same time. But it sounds really good all of this. Have to start thinking about the app server design, see how we can do that. It's always a balance, since in the beginning it will be a very small nr of routes. Having the xml_curl setup is a lot of overkill there. But I also know that when connected systems increases there's no time anymore to do it properly, so it's probably best to build the rocketship right from the start. :) /robin