Hi Lin, > First, I would like to ask why Continuous Queries have much better > performance? Is it a batch packing CacheEntryEvents instead of one by one > CacheEvent?
Correct. The continuous query engine will send notifications in batches when possible. > The OPS is, > > simple-put, event-put > 143546, 6433 > 148345, 6408 > 144624, 6454 Since that every notification is processed separately triggering underlying I/O it leads to the situation with the I/O is over consumed and other operations (cache.puts) have to be processed as well. Try to switch to the continuous queries to see the difference. — Denis > On Jul 1, 2016, at 3:35 PM, Lin <m...@linlyu.com> wrote: > > Hi Denis, > > First, I would like to ask why Continuous Queries have much better > performance? Is it a batch packing CacheEntryEvents instead of one by one > CacheEvent? > > Secondly, I put the client code in the gist > https://gist.github.com/jackeylu/a4f8b1f4dbb4c55031becfa036a5cb34 , I think > you can reproduce the result easily. > > *. CacheOperations.java is the basic putting operations. > *. ignite.xml is the configuration file used for client and servers. > *. IgniteClientCacheEventPut.java is the benchmark code for putting with > event listener. > *. IgniteClientSimplePut.java is the benchmark code for putting only. > *. TimeRecord.java is a time consumer record. > *. Format.java provided OPS computing. > *. start-server.sh > *. start-simple-client.sh > *. start-event-client.sh > > I start the two cache servers in two servers with start-server.sh and > ignite.xml, and then start the simple client with start-simple-client.sh > ignite.xml 128, when it is done, > start-event-client.sh ignite.xml 128. > > The OPS is, > > simple-put, event-put > 143546, 6433 > 148345, 6408 > 144624, 6454 > > > Thanks for your help. > > Regards, > > Lin > > > ------------------ Original ------------------ > From: "Denis Magda";<dma...@gridgain.com>; > Date: Thu, Jun 30, 2016 09:29 PM > To: "user"<user@ignite.apache.org>; > Subject: Re: performance of CacheEvents > > Hi Lin, > > First of all, I would suggest using Continuous Queries [1] since this > functionality provide much stronger delivery guarantees rather than basic > events sub-system. > > Next, how your benchmark looks like? Just want to see what and how you > measure. > > [1] https://apacheignite.readme.io/docs/continuous-queries > <https://apacheignite.readme.io/docs/continuous-queries> > > — > Denis > >> On Jun 30, 2016, at 12:36 PM, Lin <m...@linlyu.com <mailto:m...@linlyu.com>> >> wrote: >> >> It looks like the bottleneck is the bandwidth, the eth is 1Gb, the bandwidth >> received in the client is 121 MB, it is almost reach the physical upper >> bound. >> >> Can I remove or cut off some contents in the CacheEvent? Or using the custom >> event? >> >> >> ------------------ Original ------------------ >> From: "Lin";<m...@linlyu.com <mailto:m...@linlyu.com>>; >> Date: Thu, Jun 30, 2016 04:42 PM >> To: "user"<user@ignite.apache.org <mailto:user@ignite.apache.org>>; >> Subject: performance of CacheEvents >> >> Hi all, >> >> I have one client node and two server node, the client registered only two >> events on a specified cache "cache1" , >> the EventType.EVT_CACHE_OBJECT_PUT and EventType.EVT_CACHE_OBJECT_REMOVED. >> >> Compared with no events case, we test the cache puts operation with >> yardstick. >> The OPS of cache puts can reach 70K OPS in the client, but only 5K OPS in >> the events case. >> >> I know the housands of events per second will lead to performance >> degradation, and I have just enable the two events. >> If I have to enable these two events, could you tell me how to or can I >> improve the performance? >> >> PS: My network interface's bandwitdh is 1G, and the CPU loads is 15.4%, the >> used memory is 6.4G(total is 64G). >> >> Best regards >> Lin >
