Tarantool development patches archive
 help / color / mirror / Atom feed
From: Konstantin Osipov <kostja@tarantool.org>
To: tarantool-patches@freelists.org
Cc: Serge Petrenko <sergepetrenko@tarantool.org>
Subject: [tarantool-patches] Re: [PATCH v2] iproto: introduce a proxy module.
Date: Tue, 16 Oct 2018 21:35:16 +0300	[thread overview]
Message-ID: <20181016183516.GD5454@chai> (raw)
In-Reply-To: <20181008104454.k7mj7sb4vhlrgbwa@esperanza>

* Vladimir Davydov <vdavydov.dev@gmail.com> [18/10/08 13:54]:
> On Tue, Oct 02, 2018 at 09:05:54PM +0300, Serge Petrenko wrote:
> > By default, upon new client connection, all requests from the client are
> > forwarded through "guest" connection. Upon recieving an AUTH request,
> > proxy processes it on a local instance (this can be done, since proxy is
> > being run on one of the cluster instances and has access to user data).
> > If auth is successful, new client requests are forwarded through
> > corresponding user connection, otherwise, proxy keeps forwarding request
> > through guest connection.
> 
> Before diving in the code, I'd like to inquire why you think that a
> proxy should forward all user connections with the same credentials
> through a single connection to the master. AFAIU this complicates the
> implementation quite a bit and may negatively affect performance as
> this design implies joggling with sync sequences.
> 
> What if the user deliberately created several connections so as to
> avoid throttling certain transactions on hitting the network buffer
> limit? I don't think that it's right to push all requests through
> the same queue then.

It's a good question and we need to bench it.

Generally using fewer sockets to marshal requests is cheaper on
the server side, since it has to perform fewer syscalls to read
data from network.

But it depends on the actual load. For example, if all your
clients are already multiplexing requests, you're simply
performing useless work. But if your typical client is
"simple,stupid", e.g. request/response style, then you're
saving quite a bit of server CPU time. This can be easily  
seen in a  nosqlbench test.

I'd say a typical client is simple, stupid, so multiplexing for it is
useful. If you want to be real smart, you could turn multiplexing
on/off depending on request/response rate (turn it off for highly
loaded connections). But that's an optimization, as a general rule
the proxy has to do multiplexing.

-- 
Konstantin Osipov, Moscow, Russia, +7 903 626 22 32
http://tarantool.io - www.twitter.com/kostja_osipov

  reply	other threads:[~2018-10-16 18:35 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-02 18:05 [tarantool-patches] " Serge Petrenko
2018-10-03  8:49 ` Vladimir Davydov
2018-10-04 11:54 ` [tarantool-patches] " Georgy Kirichenko
2018-10-08 10:44 ` [tarantool-patches] " Vladimir Davydov
2018-10-16 18:35   ` Konstantin Osipov [this message]
2018-10-08 16:48 ` Vladimir Davydov
2018-10-16 18:39   ` [tarantool-patches] " Konstantin Osipov
2018-10-17  8:35     ` Vladimir Davydov
2018-10-17 15:31       ` Konstantin Osipov
2018-10-08 19:45 ` [tarantool-patches] " Vladimir Davydov
2018-10-16 18:42   ` [tarantool-patches] " Konstantin Osipov
2018-10-23 17:26 ` Konstantin Osipov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181016183516.GD5454@chai \
    --to=kostja@tarantool.org \
    --cc=sergepetrenko@tarantool.org \
    --cc=tarantool-patches@freelists.org \
    --subject='[tarantool-patches] Re: [PATCH v2] iproto: introduce a proxy module.' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox