Unix sockets vs. localhost: We posted a lot of tuning advice on this blog already. Now we thought we would take it a step further and share some more advice and common “mistakes” that we see people making when configuring web applications. Improving web application performance is more critical than ever, because most applications in use are browser-based.
Table of Contents
In most cases, web applications run a large number of very small statements. In some cases, the database is even on the same server as the application itself.
To run small statements on the same host, PostgreSQL provides two means:
Most people don't really care. “localhost” is as good as a UNIX socket …
Well - it is not!
a.sql is a simple script, which just creates a random number and SELECTs it. So it is the most simplistic statement possible. There is nothing simpler than just fetching a number.
So, let us run this benchmark on a normal laptop:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
[hs@zenbook postgresql-9.5.0]$ pgbench -f /tmp/a.sql -j 5 -c 10 -T 10 test starting vacuum...end. transaction type: Custom query scaling factor: 1 query mode: simple number of clients: 10 number of threads: 5 duration: 10 s number of transactions actually processed: 791171 latency average: 0.126 ms tps = 79096.447917 (including connections establishing) tps = 79136.229601 (excluding connections establishing) |
The interesting thing is that the average latency is 0.126 milliseconds.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
[hs@zenbook postgresql-9.5.0]$ pgbench -f /tmp/a.sql -j 5 -c 10 -T 10 -h localhost test starting vacuum...end. transaction type: Custom query scaling factor: 1 query mode: simple number of clients: 10 number of threads: 5 duration: 10 s number of transactions actually processed: 473210 latency average: 0.211 ms tps = 47297.885523 (including connections establishing) tps = 47331.482977 (excluding connections establishing) |
The latency skyrockets from 0.126 ms to 0.211 milliseconds. At the same time TPS drop from 79.000 to 47.300.
NOTE: In real life, the drop won't be that large because we expect users to run slightly more complicated SQL - however, the difference is real and there.
Why is that? UNIX sockets are actually a pretty simple thing. The loopback device is much more complicated and therefore the overhead relative to those simple queries is huge.
In case you need any assistance, please feel free to contact us.
In order to receive regular updates on important changes in PostgreSQL, subscribe to our newsletter, or follow us on Facebook or LinkedIn.
You need to load content from reCAPTCHA to submit the form. Please note that doing so will share data with third-party providers.
More InformationYou are currently viewing a placeholder content from Facebook. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More InformationYou are currently viewing a placeholder content from X. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More Information
Nice, thanks for sharing the info! 🙂
This is an interesting observation, especially as some people seem to be eager to move everything to micro services which communicate via TCP instead of syscalls or domain sockets.
In this blog post, I have shared some observations about the same topic: http://troelsarvin.blogspot.dk/2010/06/separation-or-co-location-of-database.html
i wonder about the numbers when if PGHOST=/tmp
just to clarify, by UNIX socket you mean PGHOST=/tmp and not TCP sockets, correct?