-
Notifications
You must be signed in to change notification settings - Fork 529
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chronice-queue performance on win os seems very slow. #96
Comments
I am not so familiar with the reactor library but will look into it Can you provide a complete example as the reactor configuration doesn't Note: we don't support win xp for free (as Microsoft doesn't) but will make Note2: Microsoft are withdrawing sale of versions before windows 8.1 and in
|
thanks for feed back. by the way, the configuration for reactor is the default one which is packaged in the jar like this: A thread pool executor dispatcher, named threadPoolExecutorreactor.dispatchers.threadPoolExecutor.type = threadPoolExecutor Backlog is how many Task objects to warm up internallyreactor.dispatchers.threadPoolExecutor.backlog = 2048 An event loop dispatcher, named eventLoopreactor.dispatchers.ringBufferGroup.type = ringBufferGroup A ring buffer dispatcher, named ringBufferreactor.dispatchers.ringBuffer.type = ringBuffer A work queue dispatcher, named workQueuereactor.dispatchers.workQueue.type = workQueue The dispatcher named ringBuffer should be the default dispatcherreactor.dispatchers.default = ringBuffer If windows support is not supported as well for free I would switch to linux for testing. for it actually performed very slow I didn't know why. |
Thank you for the break down. Nothing particularly odd here. Are you able to produce a self contained test I could run so I can see if I On 4 November 2014 05:21, bwzhang2012 notifications@github.com wrote:
|
sure. but you should find the dependency to run import net.openhft.chronicle.ChronicleConfig; public class TestPersistQueue {
} you could add such into your project. then you should download the reactor 、disruptor 、kryo(the left is the chronicle-queue related jar)in your classpath (or make some pom file to include that) |
I tried to work out what the maven pom.xml would look like but there http://search.maven.org/#search%7Cga%7C1%7Creactor Can you provide a pom.xml which has the versions you are actually using? On 4 November 2014 10:14, bwzhang2012 notifications@github.com wrote:
|
While not a direct answer to your question, you might find this helpful. You will notice that I warmed up the code before benchmarking it. This Output To speed this up further I would use StringBuilder instead of String and import net.openhft.chronicle.*; import java.io.IOException; public class TestChronicleQueue {
// System.out.println("1===" + person);
cost==={" + (t3 - t2) + "}ms for "+count+" entries.");
person.setInfo(String.valueOf(System.currentTimeMillis()).getBytes());
} import java.io.Externalizable; public class Person implements Externalizable {
} import java.io.Externalizable; public class Person implements Externalizable {
}
On 4 November 2014 10:41, Peter Lawrey peter.lawrey@gmail.com wrote:
|
peter thanks a lot for your feedback. I just test in in pure java lib way with those libs under lib directory. as I mentioned above the reactor is spring reactor while the access site is https://github.com/reactor/reactor. and excuse me for not found in the maven. and you could take a look at the code in spring way just access it: IndexedChronicleQueuePersistor. the obvious difference is the reactor will use the codec (like kryo: you could get it by accessing https://github.com/EsotericSoftware/kryo) to serialize it into the byteBuf (defined in reactor) and then make use of chronice to write it to the appender. others will resemble the same but your example did provide use some direct way to integrate chronice. |
We use maven to save time as we have to be efficient is how we work (there I was considering adding this test to our automated build system, but there On 4 November 2014 13:55, bwzhang2012 notifications@github.com wrote:
|
Thanks a lot peter. and I will hand it to reactor team for their evaluation. |
Hi,peter. while I try to use the persistQueue with reactor(https://github.com/reactor/reactor) integration with chronice-queue (just pay some time to look at the class IndexedChronicleQueuePersistor which located in reactor.queue package). I made some simple wrapper class for testing and the performance is very slow in win os. just like
import java.io.IOException;
import net.openhft.chronicle.ChronicleConfig;
import reactor.io.Buffer;
import reactor.io.encoding.Codec;
import reactor.io.encoding.kryo.KryoCodec;
import reactor.queue.IndexedChronicleQueuePersistor;
import reactor.queue.PersistentQueue;
import reactor.queue.QueuePersistor;
import com.zjht.channel.component.util.string.RandomHelper;
import com.zjht.channel.spi.msg.transfer.ChannelTransferMsg;
import com.zjht.channel.spi.util.FilePathHelper;
public class TestPersistQueue {
}
here comes the test result in my notebook(windows xp 32bit and JDK1.7.0_65):
offer cost==={312}ms,poll cost==={109}ms
after poll1 queue===true
after poll2 queue===true
so would you mind sparing sometime to locate where my problem for I did think the performance should not reduce so heavily if compared with in-memory way.
The text was updated successfully, but these errors were encountered: