borked

Dissing Wowza "because it's Java-based, therefore crap" is childish. You won't show any config options (which I'm sure are well-tuned), what you are serving (live, static), what protocol (rtmpt urgh), video framerate vs WMS and flash client bufferLength setup, system setups, RAID configuration, more dstat outputs (-c -d -g -i -l -m -n -p -s -t -y), system OS, kernel vers, java version nothing.

Javas performace is often as comparable as anything compiled with C. Where it falls short in comparison is on I/O, since C's buffered I/O is filled internally by large file reads (although Java's FileChannel with a wrapped array ByteBuffer isn't too shabby).

[total-memory-mb] = ([stream-bitrate-kbps]/([1024-kb-per-mb]*[8-bits-per-byte])) * [chunkDurationTarget-seconds] * [maxChunkCount]

so if memory isn't a problem, which with 32GB RAM doesn't seem to be, you can assign max RAM to the java server on startup and start to offload disk input and network output by filling up the ram with more chunks.

your problem clearly lies with disk input as those values are huge and as wowza can only deliver as fast as it can get the data, the limiting point seems to be the reading of the files, pushing up cpu cycles. Having WMS sitting on SSD's has no beneficial effect in this case - having your content on SSDs would.

Apache Tomcat (Java) performance is 100% comparable with Apache HTTP (C) when configured correctly for the needs it serves, but can also be 0% crap if badly configured (as can HTTP for that matter). I'd say WMS (or adobe's flavour) is far more suited for this type of media since it is far more configurable that anything else out there in C and given the ever increasing platforms/stream types that need to be served from the same file base, configuring the server for each stream type can only be a good thing.

__________________

For coding work - hit me up on andy // borkedcoder // com
(consider figuring out the email as test #1)