You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by Himetic <ca...@theplatform.com> on 2016/10/04 00:40:01 UTC

Performance issues with Ignite L2 cache compared to ehcache

So I've got the L2 ignite cache working, confirmed with beans, logging, etc,
and we're comparing it to our existing ehcache implementation. 
Unfortunately, so far it seems to be running far fewer operations per second
than the ehcache version.  However, it does seem like the timing on each
cache query (we query by id) is fairly fast, around 5ms per query.

My suspicion is that it's because of how we're doing the batch queries - we
get the ids from querying the database with whatever parameters we're
getting from the web api, and then we go through each id and try the cache,
pooling the rest into a big database query.  I'm guessing that, since ignite
has the overhead of a network call, even if it's relatively minor when
querying for a single id, it could add up to a big delay when querying for
hundreds of IDs, compared to hitting local ehcache, even if the ehcache has
fewer hits and results in a larger query against the database ultimately.

Is there a way to mitigate this problem?  Maybe a way to do a batch query
against the L2 database?  I'm guessing not, but otherwise I'm not sure what
else we could do to avoid these performance issues.



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Performance-issues-with-Ignite-L2-cache-compared-to-ehcache-tp8069.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Performance issues with Ignite L2 cache compared to ehcache

Posted by vkulichenko <va...@gmail.com>.
Hi,

If you compare local ehcache and distributed Ignite, then it's not really
fair. Ignite gives you the biggest improvement when you need to scale out
and fit more data in memory than one computer allows. If memory of one node
is enough for you, start with a single server node embedded into the
application and measure performance.

-Val



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Performance-issues-with-Ignite-L2-cache-compared-to-ehcache-tp8069p8071.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Performance issues with Ignite L2 cache compared to ehcache

Posted by vkulichenko <va...@gmail.com>.
Hi,

You can try using the cache in REPLICATED mode. In this case writes updates
can be a little slower, but reads will always be local and therefore fast.

-Val



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Performance-issues-with-Ignite-L2-cache-compared-to-ehcache-tp8069p8088.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Performance issues with Ignite L2 cache compared to ehcache

Posted by Himetic <ca...@theplatform.com>.
Let's see...

1) we've got 5 hosts running the service, each of which has an ignite
instance.
2) we currently don't have any ignite-only nodes, just the ones embedded in
the service.
3)  spring-ignitecache.xml
<http://apache-ignite-users.70518.x6.nabble.com/file/n8086/spring-ignitecache.xml>  
4) 1.7.0
5) I was tasked with trying out a distributed cache to see if it would give
us better performance than the local ehcache we're using currently.  Because
of the way we do requests, as regards batching, querying by id, etc, it may
be that a distributed cache just doesn't actually make sense for us,
unfortunately.  Failure, however, is always an option.



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Performance-issues-with-Ignite-L2-cache-compared-to-ehcache-tp8069p8086.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Performance issues with Ignite L2 cache compared to ehcache

Posted by Alexey Kuznetsov <ak...@gridgain.com>.
Hi!

Could you share with us:
1) How many hosts you are using for starting Ignite?
2) How many Ignite nodes you are staring?
3) Ignite cache config.
4) Ignite version.
5) How often data changed in cache? May be Near Cache may help in your case?
See [1] section  "Near Caches on Server Nodes"

[1] https://apacheignite.readme.io/docs/near-caches

On Tue, Oct 4, 2016 at 7:40 AM, Himetic <ca...@theplatform.com>
wrote:

> So I've got the L2 ignite cache working, confirmed with beans, logging,
> etc,
> and we're comparing it to our existing ehcache implementation.
> Unfortunately, so far it seems to be running far fewer operations per
> second
> than the ehcache version.  However, it does seem like the timing on each
> cache query (we query by id) is fairly fast, around 5ms per query.
>
> My suspicion is that it's because of how we're doing the batch queries - we
> get the ids from querying the database with whatever parameters we're
> getting from the web api, and then we go through each id and try the cache,
> pooling the rest into a big database query.  I'm guessing that, since
> ignite
> has the overhead of a network call, even if it's relatively minor when
> querying for a single id, it could add up to a big delay when querying for
> hundreds of IDs, compared to hitting local ehcache, even if the ehcache has
> fewer hits and results in a larger query against the database ultimately.
>
> Is there a way to mitigate this problem?  Maybe a way to do a batch query
> against the L2 database?  I'm guessing not, but otherwise I'm not sure what
> else we could do to avoid these performance issues.
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Performance-issues-with-Ignite-L2-cache-compared-to-
> ehcache-tp8069.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>



-- 
Alexey Kuznetsov