Specmail2001 progress

[acoliver]

I got specmail2001 working on my laptop which was too underpowered to run everything (duh). I hope to have it working in my lab on all of the boxes when I get home. We won't be able to publish numbers unless we submit them but I will probably be able to give information like "gee this week's build is slower than last weeks by a factor of 2".

[acoliver]

Today I made some progress and some negative progress. While my lab is now re-setup and no longer in pieces...it turns out my machine (badmojo) is too low on memory and/or power to run the benchmark successfully. It pauses for like 80 seconds at a time for GC and does this after few messages. This isn't that shocking really given the size of messages and stuff. I'm using JRockit but I'm going to try sun jdk5. I tried the low pause and default gc settings. I may need a bigger box to run this bench. I don't think this has anything in particular to do with JBMS so much as performance of java with low memory on a signle processor box. I'm also not on the 2.6 kernel...

[acoliver]

Whoa... I had never done any like formal benching on JRockit 5 vs Sun JDK 5 and ummm...I think Sun has a winner here. In the last generation JRockit was the winner but it wasn't a runaway like before. Prior to that (the 1.3 era), JRockit spanked Sun JDK. In this generation...Sun pulls ahead...dramtically -- at least on this setup.. I mean no contest here. JRockit actually produced connection timeouts (always a risk with TCP/IP inbound connections and a long pause in gc). Sun JDK5 is significantly faster...

[acoliver]

I do wonder if the 2.4 kernel is part of the problem...of course jrockit certified on it...

[pilhuhn]

It pauses for like 80 seconds at a time for GC and does this after few messages.

Could you try with -XX:+AggressiveHeap GC setting?
We had some very good results with this in the past. I am now curious if this would also help in your case.

[acoliver]

I can't do that ATM. I've put off the benchmarking stuff. I highly doubt aggressive heap would help in this case.

I've put the benchmarking off until we support some more routing configuration for mail sinks. Moreover its more time consuming than I thought. Subjective information however proves that we're pretty memory efficient and should scale relatively well.