Don't forget java has issues with microbenchmarks - just starting up a JVM do something in a tight loop and done. What happens is the JIT compiler hasn't compiled the code and done its job. So we need to give the JVM time to do its thing, otherwise, java is interpreting the code (slow).
In the real world, your Geode applications would be running for days/weeks/months/years and we would need to think about such things in practice. The OpenJDK team has written some testing framework to help out: http://openjdk.java.net/projects/code-tools/jmh/ The key is the JVM needs to warm up - on the client and on the server. By warming up the JVM we allow the JVM optimizer to do its thing and optimize the right code paths. Having the optimizer kick in early sometimes causes performance issues. Also just follow any host OS tuning guidance that is out there. Regards, Charlie On Tue, Mar 27, 2018 at 1:24 AM 易振华 <[email protected]> wrote: > Hello , > I us qperf tool test delay of network card , result is > 55us , The theoretical velocity should be 19,000, and the actual velocity > is 7,800. > What are the reasons for the difference? > > tcp_bw: > bw = 2.02 MB/sec > msg_size = 1 bytes > tcp_bw: > bw = 4.52 MB/sec > msg_size = 2 bytes > tcp_bw: > bw = 8.8 MB/sec > msg_size = 4 bytes > tcp_bw: > bw = 17.4 MB/sec > msg_size = 8 bytes > tcp_bw: > bw = 33.1 MB/sec > msg_size = 16 bytes > tcp_bw: > bw = 62.5 MB/sec > msg_size = 32 bytes > tcp_bw: > bw = 116 MB/sec > msg_size = 64 bytes > > tcp_lat: > latency = 56.3 us > msg_size = 1 bytes > tcp_lat: > latency = 55.5 us > msg_size = 2 bytes > tcp_lat: > latency = 54.9 us > msg_size = 4 bytes > tcp_lat: > latency = 55.6 us > msg_size = 8 bytes > tcp_lat: > latency = 55.4 us > msg_size = 16 bytes > tcp_lat: > latency = 55.4 us > msg_size = 32 bytes > tcp_lat: > latency = 55.7 us > msg_size = 64 bytes > > -- > Best regards, > 易振华 mailto:[email protected] > > -- [email protected] | +1.858.480.9722
