Performance optimization in TimedBuffer

[mreasy]

theHi,

While profiling our application, which makes excessive usage of HornetQ, org.hornetq.core.journal.impl.TimedBuffer's CheckTimer came to light, which does more Semaphore#acquire + #release than necessary.

This is related to https://issues.jboss.org/browse/HORNETQ-354, but further develops it.

Idea is that there is no need to acquire the semaphore, release it immediately, do a Thread.yield and re-enter the procedure for approximately the duration of "timeout".

I will attach a proposed patch (towards master), which shows, how this can be improved to wait sleep and therefore free CPU for a duration of 80% of timout.

This reduces CPU-load overhead of TimedBuffer in our application significantly; would love to hear your comments.

BR

Rico

[clebert.suconic]

for some reason I couldn't apply the patch.

Do you mind rebasing and sending a patch.. or even better.. a Pull Release? You could send the pull release towards my fork (clebertsuconic/master-optimization)

if you don't know how to do it... a simple patch that works here is fine.

[clebert.suconic]

Never mind.. I could figure out what you changed.. did some manual recovery here...

Anyway.. I'm not sure about this change... The reason I didn't use a nanoSleep is that it didn't work on most Linux systems and it introduced a very large latency. On your patch the system will flush only ever 500 milliseconds what is a long time in messaging terms.

We've tried nanoSleep before. I even created a native method for when there wasn't such thing on the java API. (The native method is actually still there). But I'm not sure what to do on this case since it doesn't work on every system.

Perhaps we could re-enable the nanoSleep code with some test to verify if the kernel where the system is sitting supports real time or not. (the requirement for nanosleep to work)

[clebert.suconic]

I just submitted a Pull Request that will optimize both places you mentioned: https://github.com/hornetq/hornetq/pull/735 on this thread and the ExecutorFactory

Notice that if the system doesn't support nanoSleep, this will use regular spinning (that is the current logic). It will also send a log.info

[clebert.suconic]

This got merged today.. check it out please.

[mreasy]

Thanks Clebert.

Currently on vacation, will look into it again in January and provide feedback.

[mreasy]

Tested your version and works well - thanks