ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@gridgain.com>
Subject Re: performance of CacheEvents
Date Tue, 05 Jul 2016 10:25:18 GMT
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 <https://apacheignite.readme.io/docs/continuous-queries>
> 
> —
> Denis
> 
>> On Jun 30, 2016, at 12:36 PM, Lin <me@linlyu.com <mailto: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 <mailto:me@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
> 


Mime
View raw message