Thread: TCP Overhead on Local Loopback

On Sun, Apr 1, 2012 at 1:24 PM, Ofer Israeli <oferi@checkpoint.com> wrote:
> Hi all,
>
> We are running performance tests using PG 8.3 on a Windows 2008 R2 machine
> connecting locally over TCP.

8.3 will be not supported in under a year. Time to start testing upgrades.

http://www.postgresql.org/support/versioning/

--
Rob Wultsch
wultsch@gmail.com

On 04/01/2012 06:01 PM, Andy wrote:
> You could try using Unix domain socket and see if the performance
> improves. A relevant link:

He said Windows. There are no Unix domain sockets on Windows. (And
please don't top-post)

cheers

andrew

On Sun, Apr 1, 2012 at 8:54 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> You could try using Unix domain socket and see if the performance
>> improves. A relevant link:
>
>
> He said Windows. There are no Unix domain sockets on Windows. (And please
> don't top-post)

Windows supports named pipes, which are functionally similar, but I
don't think pg supports them.

On 04/01/2012 08:29 PM, Claudio Freire wrote:
> On Sun, Apr 1, 2012 at 8:54 PM, Andrew Dunstan<andrew@dunslane.net>  wrote:
>>> You could try using Unix domain socket and see if the performance
>>> improves. A relevant link:
>>
>> He said Windows. There are no Unix domain sockets on Windows. (And please
>> don't top-post)
> Windows supports named pipes, which are functionally similar, but I
> don't think pg supports them.
>

Correct, so telling the OP to have a look at them isn't at all helpful.
And they are not supported on all Windows platforms we support either
(specifically not on XP, AIUI).

cheers

andrew

On 04/01/2012 09:11 PM, Andrew Dunstan wrote:
>
>
> On 04/01/2012 08:29 PM, Claudio Freire wrote:
>> On Sun, Apr 1, 2012 at 8:54 PM, Andrew Dunstan<andrew@dunslane.net>
>> wrote:
>>>> You could try using Unix domain socket and see if the performance
>>>> improves. A relevant link:
>>>
>>> He said Windows. There are no Unix domain sockets on Windows. (And
>>> please
>>> don't top-post)
>> Windows supports named pipes, which are functionally similar, but I
>> don't think pg supports them.
>>
>
> Correct, so telling the OP to have a look at them isn't at all
> helpful. And they are not supported on all Windows platforms we
> support either (specifically not on XP, AIUI).
>
>

Apparently I was mistaken about the availability. However, my initial
point remains. Since all our  client/server comms on Windows are over
TCP, telling the OP to look at Unix domain sockets is unhelpful.

cheers

andrew

On Sun, Apr 1, 2012 at 1:24 PM, Ofer Israeli <oferi@checkpoint.com> wrote:
> Hi all,
>
> We are running performance tests using PG 8.3 on a Windows 2008 R2 machine
> connecting locally over TCP.
> In our tests, we have found that it takes ~3ms to update a table with ~25
> columns and 60K records, with one column indexed.

I assume you mean 3ms per row, as per 3ms per 60,000 rows (or per
5,000 rows?) seems improbably fast.

> We have reached this number after many tweaks of the database configuraiton
> and one of the changes we made was to perform the updates in batches of 5K
> as opposed to the pervious transaction per event.  Note that our use of
> batches is to have only one transaction, but still each of the 5K events is
> independently SELECTing and UPDATEing records, i.e. it is not all contained
> in a stored procedure or such.
>
> Still these times are too high for us and we are looking to lower them and I
> am wondering about the TCP/IP overhead of passing the information back and
> forth.  Does anyone have any numbers in what the TCP could cost in the
> configuration mentioned above or pointers on how to test it?

Change all your updates to selects, with the same where clause.  If
doing that makes it much faster, TCP must not have been your
bottleneck.


Cheers,

Jeff

On Sun, Apr 2, 2012 at 11:25 AM, Samuel Gendler < sgendler@ideasculptor.com >  wrote:
> But suggesting moving away from TCP/IP with no actual evidence that it is network overhead that is the problem is a
littlepremature, regardless.   

Agreed, that's why I'd like to understand what tools / methodologies are available in order to test whether TCP is the
issue.

> What, exactly, are the set of operations that each update is performing and is there any way to batch them into fewer
statements 
> within the transaction.  For example, could you insert all 60,000 records into a temporary table via COPY, then run
justa couple of queries to do  
> bulk inserts and bulk updates into the destination tble via joins to the temp table?

I don't see how a COPY can be faster here as I would need to both run the COPY into the temp table and then UPDATE all
thecolumns in the real table. 
Are you referring to saving the time where all the UPDATEs would be performed via a stored procedure strictly in the db
domainwithout networking back and forth? 

> 60,000 rows updated with 25 columns, 1 indexed in 3ms is not exactly slow.  That's a not insignificant quantity of
datawhich must be transferred from client to server,  
> parsed, and then written to disk, regardless of TCP overhead.  That is happening via at least 60,000 individual SQL
statementsthat are not even prepared statements.  I don't  
> imagine that TCP overhead is really the problem here.  Regardless, you can reduce both statement parse time and TCP
overheadby doing bulk inserts  
> (COPY) followed by multi-row selects/updates into the final table.  I don't know how much below 3ms you are going to
get,but that's going to be as fast  
> as you can possibly do it on your hardware, assuming the rest of your configuration is as efficient as possible.

The 3ms is per each event processing, not the whole 60K batch.  Each event processing includes:
5 SELECTs
1 DELETE
2 UPDATEs
where each query performed involves TCP connections, that is, the queries are not grouped in a stored procedure or
such.

For all these queries does 3ms sound like a reasonable time?  If so, do you have an estimation of how long the network
portionwould be here? 

Thanks,
Ofer

On Tue, Apr 3, 2012 at 12:24 PM, Ofer Israeli <oferi@checkpoint.com> wrote:
> On Sun, Apr 2, 2012 at 11:25 AM, Samuel Gendler < sgendler@ideasculptor.com >  wrote:
>> But suggesting moving away from TCP/IP with no actual evidence that it is network overhead that is the problem is a
littlepremature, regardless. 
>
> Agreed, that's why I'd like to understand what tools / methodologies are available in order to test whether TCP is
theissue. 

As it was pointed out already, if you perform 60.000 x (5+1+2) "select
1" queries you'll effectively measure TCP overhead, as planning and
execution will be down to negligible times.

>> What, exactly, are the set of operations that each update is performing and is there any way to batch them into
fewerstatements 
>> within the transaction.  For example, could you insert all 60,000 records into a temporary table via COPY, then run
justa couple of queries to do 
>> bulk inserts and bulk updates into the destination tble via joins to the temp table?
>
> I don't see how a COPY can be faster here as I would need to both run the COPY into the temp table and then UPDATE
allthe columns in the real table. 
> Are you referring to saving the time where all the UPDATEs would be performed via a stored procedure strictly in the
dbdomain without networking back and forth? 

You'll be saving a lot of planning and parsing time, as COPY is
significantly simpler to plan and parse, and the complex UPDATEs and
INSERTs required to move data from the temp table will only incur a
one-time planning cost. In general, doing it that way is significantly
faster than 480.000 separate queries. But it does depend on the
operations themselves.

>> 60,000 rows updated with 25 columns, 1 indexed in 3ms is not exactly slow.  That's a not insignificant quantity of
datawhich must be transferred from client to server, 
>> parsed, and then written to disk, regardless of TCP overhead.  That is happening via at least 60,000 individual SQL
statementsthat are not even prepared statements.  I don't 
>> imagine that TCP overhead is really the problem here.  Regardless, you can reduce both statement parse time and TCP
overheadby doing bulk inserts 
>> (COPY) followed by multi-row selects/updates into the final table.  I don't know how much below 3ms you are going to
get,but that's going to be as fast 
>> as you can possibly do it on your hardware, assuming the rest of your configuration is as efficient as possible.
>
> The 3ms is per each event processing, not the whole 60K batch.  Each event processing includes:
> 5 SELECTs
> 1 DELETE
> 2 UPDATEs
> where each query performed involves TCP connections, that is, the queries are not grouped in a stored procedure or
such.

If you run the 480.000 queries on a single transaction, you use a
single connection already. So you only have transmission overhead,
without the TCP handshake. You still might gain a bit by disabling
Nagle's algorithm (if that's possible in windows), which is the main
source of latency for TCP. But that's very low-level tinkering.

> For all these queries does 3ms sound like a reasonable time?  If so, do you have an estimation of how long the
networkportion would be here? 

You perform 8 roundtrips minimum per event, so that's 375us per query.
It doesn't look like much. That's probably Nagle and task switching
time, I don't think you can get it much lower than that, without
issuing less queries (ie: using the COPY method).

On Tue, Apr 3, 2012 at 7:04 PM, Dave Crooke <dcrooke@gmail.com> wrote:
>On Tue, Apr 3, 2012 at 10:38 AM, Claudio Freire <klaussfreire@gmail.com> wrote:
>> You perform 8 roundtrips minimum per event, so that's 375us per query.
>> It doesn't look like much. That's probably Nagle and task switching
>> time, I don't think you can get it much lower than that, without
>> issuing less queries (ie: using the COPY method).

> I may be missing something stated earlier, but surely there are options in between 7 individual statements and
resortingto COPY and temp tables. 
 

> I'm thinking of a set of precompiled queries / prepared statements along the lines of "SELECT FOR UPDATE WHERE foo in
(?,?, ?, .... ?)" that handle e.g. 500-1000 records per invocation. Or what about a stored procedure that updates one
record,performing the necessary 7 steps, and then calling that in bulk?
 

> I agree with the assessment that 375us per statement is pretty decent, and that going after the communication channel
(TCPvs local pipe) is chasing pennies when there are $100 bills lying around waiting to be collected.
 

Thanks for the suggestions.  We ended up re-factoring the code: caching some of the data that we needed in order to
eliminatesome of the queries previously run and inserting data completion into update statements in the form of UPDATE
SET... (SELECT ...) which brought us down to only one SQL query as opposed to 7 and this brings the processing time
downfrom 4.5ms (previously stated 3ms was not reproduced)  down to ~1ms which is great for us.
 


Many thanks for the help from all of you,
Ofer