Re: [xmlblaster] Durable QoS performance

[Marcel Ruff <ruff at swand.lake.de>]

Hi Doug,

thanks for the benchmark.
The durable and none durable message throughput looks very
slow.
I have made tests some month ago on a double 1.1 MHz server having 1200 
msgs/sec
(none durable) with one publisher and 5 subscribers (all of them
receiving the 1200 msg/sec). The publisher and subscribers
where running on two other hosts.
The xmlBlaster server had a CPU load of 40% with this scenario.
(The publisher was adjusted to send 1200 msg/sec).

Could you post your test code, so we can check why the CPU has
nothing to do in you case?

As i'm busy until next week, i try to look into it next week.

thanks,

Marcel

Doug.Palmer at csiro.au wrote:

> Hi,
>
> I've been running some rough'n'ready benchmarks over xmlBlaster. With
> volatile messages, I get a maximum throughput of about 360 messages per
> second. When I change the QoS to durable, the maximum throughput drops to 5
> messages per second. The performance monitor says that I'm using <5% CPU and
> only transferring 30K/s to disks. I'm used to persistent messaging being
> disk bound at about 50-100 mps for other MOM, so this seems a little on the
> low side. The tests are not tuned at all, except for
> -Dsession.maxSessions=10000 set in the server. Otherwise, everything is as
> it is out of the box.
>
> Can anyone suggest any obvious stupidities?
>
> I'm using xmlBlaster 0.79f with the Sun 1.3.1 HotSpot JVM (as supplied with
> JBuilder 6). The system I'm running on is a Dell Precision 620: 2x900 MHz
> processors, 1Gb memory, 9Gb SCSI disk, Win2k Server SP2. The benchmarks
> start a number of senders which send 4k messages to a single subscriber on a
> single subject. The server and client are running on the same machine. While
> the performance figures aren't the 600-odd mps given on the web page, there
> are plenty of reasons for that, starting with the JVM.
> 	
> Some results below. Columns are message size, demand (how many messages per
> second total I'm trying to send) number of senders/publishers, number of
> receivers/subscribers, number of keys, run time (ms), number of messages
> sent, number received, sender throughput in messages per second, receiver
> throughput in messages per second.
>
> Simple throughput, non-durable
>
> CPU multitheaded ~10% for 20mps, 20% for 100mps, 40% for 200mps, 80% for
> 500mps, 80% for 1000mps, flattens at 80%	
> Size	Deman	Sders	Rcvrs	Keys	Time		Sent	Rcvd	Sent
> Received
> 4096	10	10	1	1	119984	1200	1200	10	10
> 4096	20	10	1	1	119983	2400	2401	20	20
> 4096	50	10	1	1	120000	6000	6001	50	50
> 4096	100	10	1	1	120030	11999	12000	100	100
> 4096	200	10	1	1	119984	23981	23982	200	200
> 4096	500	10	1	1	119984	42868	42869	357	357
> 4096	1000	10	1	1	119984	43865	43866	366	366
> 4096	2000	10	1	1	119984	44026	44027	367	367
>
> Simple throughput, durable
>
> < 5% CPU disk: ~5 transfers/s, ~5% disk time, ~30K/s
>
> Size	Deman	Sders	Rcvrs	Keys	Time		Sent	Rcvd	Sent
> Received
> 4096	10	10	1	1	120093	642	643	5	5
> 4096	20	10	1	1	120000	643	644	5	5
> 4096	50	10	1	1	119984	642	643	5	5
> 4096	100	10	1	1	119984	644	645	5	5
> 4096	200	10	1	1	120000	642	643	5	5
> 4096	500	10	1	1	119984	642	643	5	5
>
> Increase number of subscribers, non-durable
>
> Size	Deman	Sders	Rcvrs	Keys	Time		Sent	Rcvd	Sent
> Received
> 4096	100	10	1	1	120031	12000	12001	100	100
> 4096	100	10	2	1	119999	12000	23600	100	197
> 4096	100	10	5	1	120030	12000	58483	100	487
> 4096	100	10	10	1	119999	8443	81919	70	683
> 4096	100	10	20	1	120030	3669	68499	31	571
> 4096	100	10	50	1	120030	1516	66148	13	551
> 4096	100	10	100	1	120030	982	84889	8	707
>
>