2016-06-08 8:26 GMT+02:00 Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp >:
> At Tue, 7 Jun 2016 12:18:31 +0200, Magnus Hagander <mag...@hagander.net> > wrote in < > cabuevez5qrmq4ebysbz+ujfg_3_ap361zqtgbh_ef+2j6p0...@mail.gmail.com> > > On Tue, Jun 7, 2016 at 11:31 AM, Pavel Stehule <pavel.steh...@gmail.com> > > wrote: > > >> That's definitely not expected behavior. hostnossl should turn off ssl > > >> which should turn off the overhead completely. Does it make a > difference if > > >> you also disable it from the client side? > > >> > > > > > > When I explicitly disabled ssl, then I seen significantly less time > > > > > > > > Intersting. Can you check with a network trace that it actually turns off > > ssl, so nothing is broken there? > > > > One thing that could be taking the time is an extra roundtrip -- e.g. it > > tries to connect with ssl fails and retries without. A network trace > should > > also make this obvious, and can hopefully show you exactly where in the > > connection the time is spent. > > As Tom said, setting sslmode=allow or disable prevents > reconnection against hostnossl. > > > psql "sslmode=disable host=127.0.0.1 dbname=postgres" > > There are 4 (disable, allow, prefer, require) * 3 (host, hostssl, > hostnossl) = 12 possible combinations (ignoring veryfy-* of > sslmode) of SSL usage preferences. Among these, the following two > combinations needs reconnection. > > prefer + hostnossl , allow + hostssl > > Since no client can find whether a user can connect using (or not > using) SSL before making any connection, reconnection is > inevitable for the above combinations. > > By the way, SSL initialization takes place only when server is > requested SSL connection (NEGOTIATE_SSL_MODE), so only prefer + > hostnossl causes the wasting SSL intialization. > Thank you for detailed info Regards Pavel > > regards, > > -- > Kyotaro Horiguchi > NTT Open Source Software Center > > >
