Return-Path: X-Original-To: apmail-ignite-user-archive@minotaur.apache.org Delivered-To: apmail-ignite-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1A66E1835F for ; Wed, 10 Feb 2016 19:52:06 +0000 (UTC) Received: (qmail 43947 invoked by uid 500); 10 Feb 2016 19:52:05 -0000 Delivered-To: apmail-ignite-user-archive@ignite.apache.org Received: (qmail 43904 invoked by uid 500); 10 Feb 2016 19:52:05 -0000 Mailing-List: contact user-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@ignite.apache.org Delivered-To: mailing list user@ignite.apache.org Received: (qmail 43894 invoked by uid 99); 10 Feb 2016 19:52:05 -0000 Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Feb 2016 19:52:05 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 6C5FDC1149 for ; Wed, 10 Feb 2016 19:52:05 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.173 X-Spam-Level: ** X-Spam-Status: No, score=2.173 tagged_above=-999 required=6.31 tests=[DKIM_ADSP_CUSTOM_MED=0.001, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.972] autolearn=disabled Received: from mx1-us-east.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id 6CRMeJcLfFCC for ; Wed, 10 Feb 2016 19:52:04 +0000 (UTC) Received: from mbob.nabble.com (mbob.nabble.com [162.253.133.15]) by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org) with ESMTP id 807DF42A40 for ; Wed, 10 Feb 2016 19:52:04 +0000 (UTC) Received: from malf.nabble.com (unknown [162.253.133.59]) by mbob.nabble.com (Postfix) with ESMTP id 05299207658D for ; Wed, 10 Feb 2016 11:46:09 -0800 (PST) Date: Wed, 10 Feb 2016 11:40:22 -0800 (PST) From: vkulichenko To: user@ignite.apache.org Message-ID: <1455133222618-2938.post@n6.nabble.com> In-Reply-To: <1455119113214-2934.post@n6.nabble.com> References: <1454511995543-2819.post@n6.nabble.com> <1454536106871-2823.post@n6.nabble.com> <1454641873886-2844.post@n6.nabble.com> <1455119113214-2934.post@n6.nabble.com> Subject: Re: Data grid Load balancing MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Vinay, Replicated cache works like a partition cache with backups on all nodes (plus several specific optimizations). So in replicated cache there is still primary node for any key and client request will go to that node (i.e., affinity behavior is similar to partitioned cache, you're right here). vinshar wrote > if above point 2 is correct then, Do you think there will be any gain if > in case of replicated caches we use round robin or weight based or current > server load / performance based strategy to decide which server node to > send a request for a cache operation? or will it be an overkill because in > case of cache operations (other than get) which changes something in cache > will anyway will propagate to other server nodes. and it may also be an > overkill in case if near cache is utilized by clients. In vast majority of use cases clients request a lot of different keys and current architecture guarantees that in such cases requests will be spreaded across different nodes. I believe this is correct default behavior, but you can always override it using Compute Grid. Default affinity function is RendezvousAffinityFunction. -Val -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Data-grid-Load-balancing-tp2819p2938.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.