[JDEV] MIU, was: MSN transport questions

[Michael Poole]

Alexey Shchepin <alexey at sevcom.net> writes:

> Hello, lukasm!
>
> On Wed, 03 Sep 2003 15:04:06 +0200, you said:
>
>  >> Why that? As far as I remember my courses C and Java have the same
>  >> expressive power.
>  >> 
>  l> Java is 6-10 times slower than C.
>
> Usually transports spend most of time inside select (poll, kqueue, etc) call.
> And usually transport only parse packet and change its format.  So you can
> write it in language that 100 times slower than C, and it still will be able to
> process hundreds of packets in second.  But you will spend 10 times less time
> than programming it in C.

Do not assume that input polling will dominate the timing profile for
Jabber.  When you have dozens or hundreds of clients active on a
server, it may.  When you have thousands, it probably will not.

How many messages per second can your transport handle right now, if
for each one it has to decrypt data, parse XML, stringprep, process
and rewrite, format XML, and encrypt?  What happens when you have
groupchat and you have to perform the "rewrite, format XML, encrypt"
steps several times for each message?

One moderately large IRC server (~6,000 clients) on a medium sized IRC
network (~40,000 clients peak) has been up for 56 days and received
1.4 billion lines; each line would be a full stanza in native Jabber.
650 million lines were real messages.  That averages to 3000 and 1350
lines per second respectively.  If you want to seriously compete, that
is the performance level you should aim at.

That server spends most of its CPU time busy in poll(); a comparable
server on the same network spends most of its time idle in kevent(),
due to the differences in overhead for those two APIs.  If they had to
decrypt incoming data and encrypt the outgoing data, I suspect that
they would spend more time in userspace than the kernel.  Jabber
requires significantly more processing than that.  That environment
may be larger than typical Jabber deployments, but it should not be
ignored.

Michael Poole