Re: PATCH:do not set Win32 server-side socket buffer size on windows 2012

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, chenhj <chjischj(at)163(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PATCH:do not set Win32 server-side socket buffer size on windows 2012
Date: 2015-07-03 08:49:44
Message-ID: CAKJS1f-Zs_khaD_iBnEubjjY6JRDc3GE4kGdfSj9NEJvUQJobA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3 July 2015 at 20:06, Andres Freund <andres(at)anarazel(dot)de> wrote:

> On 2015-07-02 23:56:16 +0300, Heikki Linnakangas wrote:
> > On 04/10/2015 01:46 PM, chenhj wrote:
> > >Result(execute time):
> > >default(8K), 7.370s
> > >set SO_SNDBUF to 32K, 4.159s(the current implement)
> > >set SO_SNDBUF to 64K, 2.875s
> > >set SO_SNDBUF to 128K, 1.593s
> > >set SO_SNDBUF to 256K, 1.324s
> >
> > I was about to commit the attached, but when I tested this between my
> > Windows 8.1 virtual machine and Linux host, I was not able to see any
> > performance difference. It may be because the case is hobbled by other
> > inefficiencies, in the virtualization or somewhere else, but I wonder if
> > others can reproduce the speedup?
>
> Given that too small sockets incur significantly smaller latency bumps
> in a virtualized environment than in a real network, and hit another set
> of buffers inside the virtualization technology,, I'm not particularly
> surprised by that.
>
>
I'm wondering what the original test setup was. I'm assuming psql and
postgres both running on separate windows machines?

I've tested the patch just connecting to a database running on localhost
and I'm not getting much of a speedup. Perhaps 1%, if that's not noise. I
don't have enough hardware here to have client and server on separate
machines, at least not with a stable network that goes through copper.

Here's the results.

Unpatched:

-- 100MB
Measure-Command { .\psql.exe -d postgres -t -A -c "select
'1'::char(10000000),generate_series(1,10)" > $null }

TotalMilliseconds : 1997.3908
TotalMilliseconds : 2111.4119
TotalMilliseconds : 2040.4415
TotalMilliseconds : 2167.5532
TotalMilliseconds : 2087.6444
TotalMilliseconds : 2117.3759
TotalMilliseconds : 2100.3229
TotalMilliseconds : 2132.3522
TotalMilliseconds : 2129.9487
TotalMilliseconds : 2101.675

Median: 2106.54345
Average: 2098.61165

-- 500MB
Measure-Command { .\psql.exe -d postgres -t -A -c "select
'1'::char(10000000),generate_series(1,50)" > $null }

TotalMilliseconds : 10344.4251
TotalMilliseconds : 10248.3671
TotalMilliseconds : 10370.3856
TotalMilliseconds : 10412.507
TotalMilliseconds : 10469.173
TotalMilliseconds : 10248.8889
TotalMilliseconds : 10331.9476
TotalMilliseconds : 10320.7841
TotalMilliseconds : 10470.3022
TotalMilliseconds : 10333.4203

Median: 10338.9227
Average: 10355.02009

Patched:

-- 100MB
Measure-Command { .\psql.exe -d postgres -t -A -c "select
'1'::char(10000000),generate_series(1,10)" > $null }

TotalMilliseconds : 2066.3701
TotalMilliseconds : 2106.6628
TotalMilliseconds : 2110.2459
TotalMilliseconds : 2047.8337
TotalMilliseconds : 2081.9166
TotalMilliseconds : 2034.7086
TotalMilliseconds : 2082.9072
TotalMilliseconds : 2146.6878
TotalMilliseconds : 2133.351
TotalMilliseconds : 2076.6862

Median: 2082.4119
Average: 2088.73699

-- 500MB
Measure-Command { .\psql.exe -d postgres -t -A -c "select
'1'::char(10000000),generate_series(1,50)" > $null }

TotalMilliseconds : 10217.4794
TotalMilliseconds : 10244.8074
TotalMilliseconds : 10451.7265
TotalMilliseconds : 10162.9862
TotalMilliseconds : 10304.1866
TotalMilliseconds : 10374.7922
TotalMilliseconds : 10227.9632
TotalMilliseconds : 10145.5825
TotalMilliseconds : 10298.7048
TotalMilliseconds : 10170.3754

Median: 10236.3853
Average: 10259.86042

Comparison (Unpatched / Patched)
100MB 500MB
Median 101.16% 101.00%
Average 100.47% 100.93%

Regards

David Rowley

--
David Rowley http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2015-07-03 08:54:52 Re: PATCH: pgbench - remove thread fork-emulation
Previous Message Sawada Masahiko 2015-07-03 08:25:34 Re: Freeze avoidance of very large table.