ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lin" ...@linlyu.com>
Subject 回复: performance of CacheEvents
Date Wed, 06 Jul 2016 07:09:55 GMT
Thank you, Denis.


I understood, i will try it.




------------------ 原始邮件 ------------------
发件人: "Denis Magda"<dmagda@gridgain.com>; 
发送时间: 2016年7月5日(星期二) 晚上6:25
收件人: "Ignite user group"<user@ignite.apache.org>; 
主题: Re: performance of CacheEvents



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 <me@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";<dmagda@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


—
Denis

On Jun 30, 2016, at 12:36 PM, Lin <me@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";<me@linlyu.com>;
Date:  Thu, Jun 30, 2016 04:42 PM
To:  "user"<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
Mime
View raw message