Configuring the socket for PHP-FPM monitoring

Generally now we configure the PHP Web environment, such as LNMP (linux+nginx+mysql+php), where Linux may be CentOS, Ubuntu ..., the database may be Mysql, PostgreSQL, SQL Server, etc...

Install PHP-FPM on the server, Nginx, we want to configure the Nginx HTTP module, let. php file from Nginx to PHP-FPM processing, and then in the PHP-FPM processing results through the HTTP response to the browser, completed an HTTP request.

When configuring the Nginx HTTP module, this is usually the case:

server ~ \.php$ {    include snippets/fastcgi-php.conf; fastcgi_pass 127.0.0.1:9000;}

You can do that, too.

server ~ \.php$ {    include snippets/fastcgi-php.conf; fastcgi_pass unix:/var/run/php5-fpm.sock;}

So what is the difference between these two ways??

This is the question I want to explain in this blog post. Below, I take you to analyze the principle of the one, and some of my understanding, the wrong place also please everyone, I will be grateful ~ ~

PHP-FPM can listen on multiple sockets. I also listen on Unix sockets, or TCP sockets. See how the works and how to ensure Nginx are properly sending requests to PHP-FPM.

Command Rundowndefault Configuration

Edit PHP-FPM Configuration

# Configure PHP-FPM default resource poolsudo vim /etc/php5/fpm/pool.d/www.conf

PHP-FPM Listen Configuration:

# Stuff omittedlisten = /var/run/php5-fpm.socklisten.owner = www-datalisten.group = www-data

Also edit Nginx and see where it's sending request to PHP-FPM:

# Files: /etc/nginx/sites-available/default# ... stuff omittedserver ~ \.php$ {    include snippets/fastcgi-php.conf; fastcgi_pass unix:/var/run/php5-fpm.sock;}

We can see above this Nginx is sending requests to php-fpm via a UNIX sockets (faux file) at /var/run/php5-fpm.sock . This is also where the www.conf file is setting PHP-FPM to listen for connections.

Unix Sockets

These is secure in that they is file-based and can ' t be read by remote servers. We can further use the Linux permission to set who can read and write to the this socket file.

Nginx is run as User/group www-data . PHP-FPM ' s UNIX socket therefore needs to is readable/writable by the this user.

If we change the Unix socket owner to User/group ubuntu , Nginx would then return a bad gateway error, as it can no longer co Mmunicate to the socket file. We would has to change Nginx to run as user "Ubuntu" as well, or set the socket file to allow "other" (non user nor group ) to was read/written to, which is insecure.

# Stuff omittedlisten = /var/run/php5-fpm.socklisten.owner = ubuntulisten.group = ubuntu

So, file permissions is the security mechanism for PHP-FPM when using a UNIX socket. The Faux-file ' s user/group and it's user/group/other permissions determines what local users and processes and read and WR ITE to the PHP-FPM socket.

TCP Sockets

Setting the Listen directive to a TCP socket (IP address and port) makes PHP-FPM Listen over the network rather than as a UNIX sockets. This makes php-fpm able to is listened to by remote servers (or still locally over the localhost network).

Change Listen to make Listen 127.0.0.1:9000 php-fpm Listen on the localhost network. For security, we can use the listen.allowed_clients rather than set the owner/group of the socket.

PHP-FPM:

# Listen on localhost port 9000Listen 127.0.0.1:9000# Ensure only localhost can connect to PHP-FPMlisten.allowed_clients = 127.0.0.1

Nginx:

# Files: /etc/nginx/sites-available/default# ... stuff omittedserver ~ \.php$ {    include snippets/fastcgi-php.conf; fastcgi_pass 127.0.0.1:9000;}

http://lists.freebsd.org/pipermail/freebsd-performance/2005-February/001143.html

UNIX domain sockets vs. Internet sockets

Robert Watson rwatson at FreeBSD.org 
Fri Feb 25 02:29:14 PST 2005

• Previous Message:unix domain sockets vs. Internet sockets
• Next Message:unix domain sockets vs. Internet sockets
• Messages sorted by: [Date] [Thread] [Subject] [Author]

On Fri, 2005, Baris Simsek wrote:>I am Coding a daemon program. I am not sure about which type of sockets>I should use. Could you compare IP Sockets and UNIX domain sockets? My>main criterions is performance and protocol load. what is the>differences between impelementations of them at kernel level?There is a few differences that might is of interest, in addition to Thealready pointed out difference so if you start Out using IP sockets, Youdon ' t has to migrate to them later when you want inter-machineconnectivity:-UNIX domain socket  s use the file system as the address name space.  This means your can use UNIX file permissions to control access to communicate with them. i.e., you can limit how other processes can connect to the daemon--maybe one user can, but the Web server can ' t, or th  e like.  With IP sockets, the ability-to-connect to your daemon are exposed off the current system, so additional steps  is taken for security.  On the other hand, you get network transparency. With UNIX domain sockets, you can actually retrieve the credential of the process that created the remote socket, and US E that for access control also, which can is quite convenient on multi-user systems.-IP sockets over localhost is basic Ally looped back network On-the-wire IP.  There is intentionally "no special knowledge" of the fact that the connection system, so no same is MA  De to bypass the normal IP stack mechanisms for performance reasons. For example, transmission over TCP would always involve, and the remote socket switches to get   Switch through the NETISR, which occurs following the "loopback" of the packet through the synthetic loopback interface.  Likewise, you get all the overhead of ACKs, TCP flow control, encapsulation/decapsulation, etc.  Routing'll be performed on order to decide if the packets go to the localhost.  Large sends'll has to is broken down into the mtu-size datagrams, which also adds overhead for Large writes. It ' s really TCP, it just goes over a loopback interface by virtue of a special address, or discovering the address Requested is served locally rather than over an Ethernet (etc). -UNIX domain sockets has explicit knowledge that they ' re executing on the same sYstem.  They avoid the extra context switch through the NETISR, and a sending thread would write the stream or datagrams directly  into the receiving socket buffer.  No checksums is calculated, no headers was inserted, no routing is performed, etc. Because They has access to the remote socket buffer, they can also directly provide feedback to the sender if it is f Illing, or more importantly, emptying, rather than have the added overhead of explicit acknowledgement and window Chan  Ges.  The one piece of functionality that UNIX domain sockets don ' t provide that TCP does is out-of-band data. In practice, a issue for almost noone. In general, the argument to implementing over TCP are that it gives youlocation independence and immediate portability--  You can move the clientor the daemon, update an address, and it'll "just work". The Socketslayer provides a reasonable abstraction of communications services, soit ' s not hard-to-write an application so that the ConnectIon/bindingportion knows about TCP and UNIX domain sockets, and all the rest justuses the socket it ' s given.  So if you ' re looking to performance Locally,i think UNIX domain sockets probably best meet your need. Many Peoplewill code to TCP anyway because performance are often less critical, andthe network portability benefit are subst Antial. Right now, the UNIX domain socket code was covered by a subsystem lock;  Ihave a version that used more Fine-grain locking, but has not yetevaluated the performance impact of those changes. I ' ve you ' re running Inan SMP environment with four processors, it could is that those changesmight positively impact PERFO  Rmance, so if you ' d like the patches, let meknow.  Right now they ' re on my schedule to start testing, and not on thepath for inclusion in FreeBSD 5.4. The primary benefit of greatergranularity would is if you had many pairs of threads/processescommunicating across Processo RS using UNIX domain sockets, and as a resultthere was substantial contEntion on the UNIX domain socket subsystem lock. The patches don ' t increase the cost of normal send/receive operations, butdue add extra mutexes operations in the LISTEN/ACC Ept/connect/bind paths. Robert N M Watson

Configuring the socket for PHP-FPM monitoring