TCP/IP is a networking communications procedure. A three-way handshake needs to first happen to develop a TCP/IP network connection prior to any data being sent out. Any data sent is first broken into smaller sized packets (this is essential for reliable network bandwidth sharing). The source and destination are included to an envelope around each data package. Error checking information is determined and added to the envelope as well. A series number is likewise added to the envelope so the receiver can fix any out of order data packets. Extra data is also added to each packet envelope to recognize and route the packet on local networks. The receiver should check and fix any out-of-order packets, check each packet for errors, send out a recognition for each packet, and reassemble the initial block of data from the information within each packet.
Keep in mind: Checksum computation and error checking is bypassed for localhost connections in contemporary Linux systems.
UDS need none of this additional fragmenting and processing of data. Because of this, UDS move information faster and more efficiently than TCP/IP.
Contemporary Linux Systems Utilizing TCP/IP With Localhost Are As Fast as UDS
If the socket() function is called with a socket domain of AF_INET or AF_INET6 (Internet protocol v4 or v6), it doesn’t matter what IP address is utilized, all communications will have the overhead of the TCP/IP procedure. UDS are a type of Inter-process Communication (IPC) which has far less processing overhead than TCP/IP.
Even if There’s Less Overhead, the Distinction in Efficiency Isn’t That Fantastic
Benchmarks reveal that changing from TCP/IP to UDS will improve connection latency and data transfer speed. The more data transferred per query, the higher the data transfer speed. Since WordPress uses big data sets and numerous database queries when saving or showing a Web page, using a UDS will improve efficiency.
UDS Aren’t Reliable and Data Corruption Is Possible
At least, in this case. There’s a type of UDS that is defined as undependable, called SOCK_DGRAM. The type=STREAM revealed by the lsof command indicates this is a SOCK_STREAM UDS which ensures delivery of a stream of ordered information. It’s highly unlikely that a database server would ever utilize a datagram UDS.
On some WordPress systems, a basic edit to your configuration file can speed up interactions in between WordPress and your database. If your WordPress setup is on Linux, and your DB_HOST setting is either localhost or 127.0.0.1, it might be possible to make use of UDS to speed up your system.
The WordPress codex mentions this strategy in their documentation on editing wp-config. If your Web server has a typical setup on Linux, the procedure could be as simple as editing a single line in the /wp-config.php file.
Utilizing localhost is preferred over 127.0.0.1 since the underlying PHP function that links to the database, mysqli_real_connect(), right away presumes the connection is to the local host if the host’s name is either NULL or ‘localhost’. Utilizing 127.0.0.1 will work too, however may be less efficient. In the end, the OS call that makes the connection doesn’t utilize the host name, just the socket path.
If you’re uncertain of the UDS path to use, you can use one of the following commands to find it:
netstat -ln | grep "unix.*mysql"
sudo lsof -U | grep mysql
These commands should work for both MariaDB and MySQL databases. If you don’t see a socket path with these commands, then UDS isn’t available to you. When doing the abovementioned modification the /wp-config.php file, for the DB_HOST, use the UDS path specific to your system.
If the database is located on the local host, then database queries will generally account for less than 6% of execution time while WordPress is processing a request. The overall effect of switching from TCP/IP to UDS will hardly be noticeable except on busy Web sites. But, given the relative ease of changing WordPress from TCP/IP to UDS, why not take whatever performance gains you can?