>> Respectfully, I wouldn't class telephony as "non-CPU-intensive". :) > > I would have thought those kinds of things are bandwidth-limited.
Typically not. Some rough numbers: a complete call setup and teardown is usually no more than 5KB, spread over the course of the call -- the initial signaling typically being less than 2KB. A gigabit ethernet link, then, can carry at least 20,000 call setups per second at 1/3 utilization (which is the point at which Ethernet starts to exhibit collisions, IIRC -- more might well be possible). Even really good SIP systems start to buckle well below 2,000cps, often as low as 200. The order of magnitude discrepancy is the time spent parsing, validating, looking up sessions, running routing logic, doing logging, switching processes and threads, etc... oh, and running your application code :) It would take a *really* fast piece of software, or a specialized appliance, to saturate a gigabit link with calls... and those almost always have multiple NICs for other reasons. This is ignoring, of course, any limitations upstream. You're unlikely to have a true gigabit link to a backbone. Then again, experience has shown that doing anything useful at all takes enough processor time that individual boxes will certainly be processor-bound for ordinary call volumes long before even a 100Mb link is saturated. 100Mb could supply all the calls an entire datacenter can handle. The reason this is an interesting domain is that, apart from logging, the entire call processing flow is in-memory and CPU-intensive. More importantly, it has latency requirements -- call setup time translates to dead air -- and even occasional slowdowns can cause a devastating cascade of retransmissions. Keeping up with requests is important, so speed is second only to reliability. >> Speed directly translates to calls-per-second. I've been very happy >> with Clojure thus far. > > Because of its competitive speed or something else? Both speed and power. I haven't noticed any performance degradation compared to my pure Java applications. For comparison, the routing logic I implemented on top of Clojure runs in 1/4 the time it takes for the Java servlet container just to parse a message from the (warm) disk cache -- I seem to recall that my code finished in 0.5ms, and the parsing in 2ms. Parsing is a very optimized part of the container! I haven't even begun profiling or optimization -- this is still a prototype. That impressed and surprised me, so much so that I actually doubled checked that everything was actually executing! (Imagine some Ruby or Python functions running in microseconds...) The commented Clojure source for the application almost seems trivial, which -- while somewhat deflating to the ego -- is a testament to how expressive the language is. I certainly wouldn't want to do this kind of exploratory development in Java (or even in CL! I use a lot of literal maps), and as things stand now there doesn't seem to be any reason to rewrite the Clojure code for performance or any other reason. I've personally written and maintained SIP servlets in Java, and they rapidly become horrific tangled webs of state machines meshed with Java methods. Not nice. Clojure, even more so than other Lisps, enables far more suitable abstractions for this kind of thing. (Some day I'll be able to write about them.) Even better, the code I've written -- thanks to STM and persistent data structures -- is very amenable to concurrency, so on an 8-core machine it'll scale safely as well as the servlet container will allow. I don't see the number of cores on our servers shrinking any time soon... Anyway, enough rambling. That's why I think telephony can be CPU intensive, and why I like Clojure :) -R --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
