From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id F2B4E24459 for ; Thu, 4 Jul 2019 04:23:46 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3aIDvywLyaC for ; Thu, 4 Jul 2019 04:22:07 -0400 (EDT) Received: from smtp46.i.mail.ru (smtp46.i.mail.ru [94.100.177.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id B9C00212F1 for ; Thu, 4 Jul 2019 04:22:07 -0400 (EDT) Date: Thu, 4 Jul 2019 11:22:05 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH 2/5] swim: sadly remove cache Message-ID: <20190704082205.GH24820@atlas> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: Vladislav Shpilevoy Cc: tarantool-patches@freelists.org * Vladislav Shpilevoy [19/07/04 10:15]: > SWIM sends basically the same message during a round. There was > a microoptimization so as not to reassemble the message on each > step. Now it is getting harder to support that island of > perfectionism, because > > * Soon all the messages will carry all the sections, > including indirect messages. Their body is smaller, so it > is not possible to maintain one cached message without > reducing its maximal size; > > * In big-clusters even without any changes a cached message > would need to be rebuilt. This is because anti-entropy > section won't help much unless it is being changed > frequent enough; > > * In big clusters changes happen often enough to invalidate > the cached message constantly, unless SWIM would had > maintained what members are included into the cache, and > which are not. Then change of a member, not included into > the message, would not affect the cache. But it would > complicate the code too much. > > Part of #4253 lgtm -- Konstantin Osipov, Moscow, Russia