Re: Performance issues with java thin client

Hello! I recommend collecting thread dumps from server nodes when you see this issue, especially by simulating many new client connections at once. Then you can triage why this would happen. Regards, -- Ilya Kasnacheev пн, 1 февр. 2021 г. в 10:18, Naveen : > Not really used with any earlier v

Re: Performance issues with java thin client

What is the size of the cluster? On Mon, Feb 1, 2021 at 10:18 AM Naveen wrote: > Not really used with any earlier versions, most of the time have used thick > clients only. > to begin with, it takes around 100 to 200 ms, slowly it goes to 1 sec and > keep increasing. > > > > > > -- > Sent from:

Re: Performance issues with java thin client

Not really used with any earlier versions, most of the time have used thick clients only. to begin with, it takes around 100 to 200 ms, slowly it goes to 1 sec and keep increasing. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Performance issues with java thin client

Hi Naveen, > seeing longer times for making connections Longer compared to previous Ignite versions? On Mon, Feb 1, 2021 at 9:23 AM Naveen wrote: > Hi > > We are using 2.8.1 and using Java thin client, seeing longer times for > making connections, there by seeing the higher latency. > How do we

Re: Performance issues with Ignite L2 cache compared to ehcache

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-e

Re: Performance issues with Ignite L2 cache compared to ehcache

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 4)

Re: Performance issues with Ignite L2 cache compared to ehcache

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 a

Re: Performance issues with Ignite L2 cache compared to ehcache

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] ht

RE: performance issues

Thanks Denis. From: Denis Magda [mailto:dma...@gridgain.com] Sent: Friday, June 24, 2016 1:00 AM To: user@ignite.apache.org Subject: Re: performance issues Hi Pradeep, Member-member (server-server) performance is better than client-server one in the scenario because in the first case roughly a

Re: performance issues

> 0.576 > 0.726 > 1.102 > > Thanks, > Pradeep V.B. > > From: Denis Magda [mailto:dma...@gridgain.com] > Sent: Thursday, June 16, 2016 6:46 PM > To: user@ignite.apache.org > Subject: Re: performance issues > > Hi, > > In a single server mode (embe

RE: performance issues

0.451 0.881 0 2 8 0.362 0.470 0.874 1 2 8 0.695 0.749 1.070 1 1 8 0.576 0.726 1.102 Thanks, Pradeep V.B. From: Denis Magda [mailto:dma...@gridgain.com] Sent: Thursday, June 16, 2016 6:46 PM To: user@ignite.apache.org Subject: Re: performance issues Hi, In a single server

Re: performance issues

Hi, In a single server mode (embedded) there is no I/O (networking) at all. All the requests are executed locally. When you use the client node you’ll have I/O delays. The performance here can depend on several factors: - latency and throughput of your network; - CPU saturation; So take a look