Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id E0AF86331EC for ; Thu, 19 Feb 2009 09:13:49 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 92054-01-4 for ; Thu, 19 Feb 2009 09:13:43 -0400 (AST) X-Greylist: delayed 00:06:39.83324 by SQLgrey-1.7.6 Received: from 39.mail-out.ovh.net (39.mail-out.ovh.net [213.251.138.60]) by mail.postgresql.org (Postfix) with SMTP id 17A196331FF for ; Thu, 19 Feb 2009 09:13:08 -0400 (AST) Received: (qmail 10992 invoked by uid 503); 19 Feb 2009 13:06:46 -0000 Received: from gw2.ovh.net (HELO mail146.ha.ovh.net) (213.251.189.202) by 39.mail-out.ovh.net with SMTP; 19 Feb 2009 13:06:46 -0000 Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 19 Feb 2009 13:06:25 -0000 Received: from par69-8-88-161-102-87.fbx.proxad.net (HELO soyouz) (88.161.102.87) by ns0.ovh.net with SMTP; 19 Feb 2009 13:06:22 -0000 Date: Thu, 19 Feb 2009 14:09:04 +0100 To: "Ross J. Reedstrom" , pgsql-performance Subject: Re: TCP network cost From: PFC Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <20090217070403.GB2486@cooker> <1ca1c1410902171013q478f2620n13fcd68cb8b3d911@mail.gmail.com> <3FAF940B-9B0B-4DBA-8728-6096022129DF@infogears.com> <20090217200416.GA23707@cooker> <20090217211454.GB23707@cooker> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <20090217211454.GB23707@cooker> User-Agent: Opera Mail/9.62 (Linux) X-Ovh-Tracer-Id: 6435080917638186582 X-Ovh-Remote: 88.161.102.87 (par69-8-88-161-102-87.fbx.proxad.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: DONE|H 0.5/N X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200902/220 X-Sequence-Number: 32801 > python w/ psycopg (or psycopg2), which wraps libpq. Same results w/ > either version. I've seen psycopg2 saturate a 100 Mbps ethernet connection (direct connection with crossover cable) between postgres server and client during a benchmark... I had to change the benchmark to not retrieve a large TEXT column to remove this bottleneck... this was last year so versions are probably different, but I don't think this matters a lot... > Note the 'bare' transfer times added above. Nothing to write home about > (~3Mb/sec) but another order of magnitude faster than the postgresql > transfer. You should test with sending a large (>100 MB) amount of data through Netcat. This should give you your maximum wire speed. Use /dev/null as the test file, and use "pv" (pipe viewer) to measure throughput : box 1 : pv < /dev/zero | nc -lp 12345 box 2 : nc (ip) 12345 >/dev/null On gigabit lan you should get 100 MB/s, on 100BaseT about 10 MB/s. If you dont get that, there is a problem somewhere (bad cable, bad NIC, slow switch/router, etc). Monitor CPU during this test (vmstat). Usage should be low.