-
1. Re: Hornetq Performance on Windows
clebert.suconic Nov 29, 2012 11:22 AM (in response to grandhivenkatesh8787)1 of 1 people found this helpfulThis is not about Windows or Linux...
HornetQ is optimized to scale up to many simultaneous producers and many simulatenous committers... but for any single source, we still have to keep the guarantees promised on the interface.
This is actually the same with most system. Even a database is optimized in the same manner. a single thread will be able to only perform 24 transactions or less per second (committs) due to the disk capabilities on sync. If you have a system doing anything beyond your hardware it's probably cheating.
that means: when you commit, we won't unblock until the hardware has finished committing.
Most fast hardware can do about 24 syncs per second, and that's what you are seeing here:
If you had two parallel producers, both should go around 24 syncs since the server will try to batch both writes in a single sync on disk.
So, in your test, if you batch your committs, you will get a much faster throughput:
if (i % 1000 == 0 && i > 0)
{
session.commit();
}
And make sure you commit the last transaction at the end.
-
2. Re: Hornetq Performance on Windows
grandhivenkatesh8787 Nov 30, 2012 4:13 AM (in response to clebert.suconic)Clebert Suconic wrote:
This is not about Windows or Linux...
HornetQ is optimized to scale up to many simultaneous producers and many simulatenous committers... but for any single source, we still have to keep the guarantees promised on the interface.
This is actually the same with most system. Even a database is optimized in the same manner. a single thread will be able to only perform 24 transactions or less per second (committs) due to the disk capabilities on sync. If you have a system doing anything beyond your hardware it's probably cheating.
that means: when you commit, we won't unblock until the hardware has finished committing.
Most fast hardware can do about 24 syncs per second, and that's what you are seeing here:
If you had two parallel producers, both should go around 24 syncs since the server will try to batch both writes in a single sync on disk.
So, in your test, if you batch your committs, you will get a much faster throughput:
if (i % 1000 == 0 && i > 0)
{
session.commit();
}
And make sure you commit the last transaction at the end.
ThankQ Clebert for your timely response...the throughput has been increased a lot....and knowledege of sync writes is very informative...