On 10 November 2017 at 16:39, Vavricka <[email protected]> wrote:
> Hi, > > hardware: > * Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz > * 16 GB RAM > * HDD ST500DM002-1BD142 > > timings: > Currently Java Broker 6.1.1 seems to behave as version 7.0.0 RC. 10 - 30 > messages per second. Interesting is when I increase message size to 10kB. > Messages per second are same but throughput is increased ten times. > When I use nonpersistent messages everything goes smooth. Thousand of 1kB > messages are sent within 1 second. > So, this is more what I would expect (in the sense that 6.1 will behave like 7.0 - the performance is unacceptable, but I think I understand it). I *think* the issue is that we have not yet implemented the optimisations in the 1.0 layer for non-transactional durable messages to be processed asynchronously. Because of this the rate of message processing is dependent upon how many times fsync() can be called a second. 500/s is probably about right for a SAN, ~20 is what I saw from conventional hard drives; for SSDs with a battery backed write cache I've gotten > 1000/s. Because it is dependent upon the number of fsyncs rather than the throughput of the disk, increasing the message size will not affect the rate and thus you will see a linear improvement in throughput. Fixing this shouldn't actually be a huge change, and after it you should see something more like the C++ broker behaviour. Since this isn't (I think) a regression between 7.0 and 6.1 I'd suggest that we progress with the 7.0 release and then quickly follow that with a 7.0.1 that introduces the necessary optimisation (we can essentially copy over the code from the 0-x protocol layers). -- Rob > > There are no extra JVM options, just the ones which are present in > bin/qpid-server file. > > Heap and direct memory on broker is also default - -Xmx512m > -XX:MaxDirectMemorySize=1536m. I tried to increase to four times larger > ones > -Xmx2048m -XX:MaxDirectMemorySize=6000m, but there was no change in > messages > per second. > > Unfortunately vmstat gives same values pro CPU, I am sending at least top > output. > > 6.1.1: > %Cpu(s): 6.9 us, 0.3 sy, 0.0 ni, 68.5 id, 24.1 wa, 0.0 hi, 0.2 si, > 0.0 > st > > 7.0.0: > %Cpu(s): 2.4 us, 0.4 sy, 0.0 ni, 71.2 id, 25.9 wa, 0.0 hi, 0.0 si, > 0.0 > st > > When we tried on server where message store was stored on SAN disk, sending > of messages increased to 500 msg/sec. With C++ broker on same machine we > are > able to send 5000 msg/sec. > > ps. I cannot create queue in 7.0.0 version by webgui when queue contains > '.' > character, in 6.1.1 version queue with dot in name can be created by webgui > > > Keith Wall wrote > > Hi Tomas, > > > > Nor can I reproduce any discernible difference in performance between > > 6.1.1 and the 7.0.0 RC with your Java code. I have not tried the C++ > > yet. > > > > Can you share with us: > > > > * details of the hardware (including the storage) you are using for the > > test. > > * the timings you seeing for your tests for both the 6.1.1 case and 7.0.0 > > RC > > * any extra JVM options you are passing either client or broker side. > > * size of java heap (client side) and heap and direct memory (broker) > > > > Can I suggest that you collect vmstat type information for both runs > > and compare? My expectation is that CPU usage, disk I/O, and network > > utilisation should be approximately equal between the two runs. > > > > cheers, Keith > > > > > > -- > Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users- > f2158936.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
