[clebert.suconic]

Another low hanging fruit :-)

MessagingImpl::decode will aways change the size of the buffer, making the Message to be bigger than it needs to be when persisting or transporting:

MessageImpl::decode
{

...
 byte[] bytes = new byte[len];
 buffer.getBytes(bytes);
 body = new BufferWrapper(1024); // this should be len
 body.putBytes(bytes);

...
}

Another point also... Making ClientProducerIimpl to use nonBlocking on transacted sends, made those to be much slower on my computer. It is taking about 200 msgs/second against 2000 as it used to be when sending blocking.

[timfox]

Another point also... Making ClientProducerIimpl to use nonBlocking on transacted sends, made those to be much slower on my computer. It is taking about 200 msgs/second against 2000 as it used to be when sending blocking.

Very strange. Did you run ant perfSenderTransactional and ant perfListenerTransactional? They high performance on my machine. Can you report your results?

I suspect something else is going on there.

[ataylor]

Another point also... Making ClientProducerIimpl to use nonBlocking on transacted sends, made those to be much slower on my computer. It is taking about 200 msgs/second against 2000 as it used to be when sending blocking.

Clebert, I ran these on my machine and the performance was fine!

[jmesnil]

"timfox" wrote:

"jmesnil" wrote:

It seems the bottleneck is the generation of the UUID.

When using UUID.randomUUID(), the implementation uses a SecureRandom.
If I use Random instead and creates the UUID with new UUID(rand.nextLong(), nextLong(), the perf increases significantely.

I don't think we should be using random UUIDs at all, since they're... well random (so can clash).

Instead I think we should use a variant 2 UUID.

After thinking a little about it, I think we do not uniquely identify the right object.
We do not need to generate a UUID for every message. We should instead generate a UUID for our MessageProducer and append a sequence number for each message sent by this producer.
This means we only need to generate a single UUID per producer. This so significantely reduces the number of generated ID that I think we can consider using a Random UUID with a unsignificant risk of clash.

If we do that our message ID will have the format: "ID:<producer uuid>:<sequence number>"

wdyt?

[timfox]

I don't like the idea of using random UUIDs for the reasons already mentioned.

[clebert.suconic]

"ataylor" wrote:

Another point also... Making ClientProducerIimpl to use nonBlocking on transacted sends, made those to be much slower on my computer. It is taking about 200 msgs/second against 2000 as it used to be when sending blocking.

Clebert, I ran these on my machine and the performance was fine!

You have to change perfSender a little for this.
You have to use it transacted, and you have to make sure you use Persistent Messages.

[timfox]

You have to change perfSender a little for this.
You have to use it transacted, and you have to make sure you use Persistent Messages.

That's what it does already!

Have you actually ran the test?

Remember we're talking about perfSenderTransactional - not perfSender!!

[jmesnil]

"trustin" wrote:

"timfox" wrote:

"timfox" wrote:

Instead I think we should use a variant 2 UUID.

http://www.webdav.org/specs/draft-leach-uuids-guids-01.txt

This might also be useful:

http://jug.safehaus.org/

Thanks for the link.

Using code from this project, I've substantially improved our perf:
disable jms message: 10133 msg/s
enabled jms message [old code]: 7183 msg/s
enabled jms message [new code]: 9806 msg/s

The same code path is 26% faster and very close to the "disable" case (97%)

[timfox]

Great!

(1000 seems pretty slow though - I can send around 30K 1K messages / sec)

[jmesnil]

"timfox" wrote:
Great!

(1000 seems pretty slow though - I can send around 30K 1K messages / sec)

If your question is "Is Apple's JVM slow and crappy", the answer is a resounding YES! :)

[timfox]

"jmesnil" wrote:

If your question is "Is Apple's JVM slow and crappy", the answer is a resounding YES! :)

See, that's what happens when you sacrifice style for performance! ;)