Ran into this issue when setting up a new VPS for AutoRidge. This happens when using Nginx and PHP-FPM with PHP 5.3+ and the Suhosin patch when trying to run a PHP script using a PHAR package. From what I can gather, the Suhosin patch basically blocks PHP include/require functions from executing files ending with .phar, which results in a PHP segfault that leaves no trace of any error at all.

His solution is a pretty simple one - edit the "suhosin.ini" file to allow for the opening of includes in phar files (suhosin.executor.include.whitelist). You can find out more about the Suhosin security tool on the project's website.

This is another wonderful setup that I've found myself using rather than the traditional Apache & mod_php setup. [...] Ngnix, unlike Apache, doesn't actually load PHP. Instead, it hands it off as a proxy to a "php handler" which acts like an Application Server. So nginx by itself won't serve PHP files, but just static files.

He briefly introduces Nginx and PHP-FPM for those not familiar and points out that this combination is very fast, even without much configuration. The packages are installed with the aptitude installer and minimal changes are made to the php-fm and nginx configuration files (mostly to set up whatever your domain/virtual host is).

Sometimes we need to serve files directly from application, especially when file access is restricted by account permissions. Using readfile() to achieve this can successfully kill our web server - even without huge load. To avoid performance problems we can use nginx X-Accel-Redirect feature, and serve files from application through nginx server.

He sets up an example situation - serving up gallery images for a basic site - and shows how to configure the nginx server with the "/gallery" directory and the PHP code you'll need to push the "X-Accel-Redirect" header along with the contents of the image.

In this tutorial, I'll show how to build a server capable of withstanding a front-page Digg placement, step by step. This will mean your business stays online when it's most important-when everyone is looking. We'll go through the process of building a super-fast, bulletproof custom web server for WordPress. The technology stack we'll use is Ubuntu, nginx, PHP-FPM, and MySQL. In a future article we'll look at adding memcached to the mix to take performance even further.

He walks you through the full install of each piece of software (on a linux-based system) even helping you compile PHP 5.3. There's some examples of configurations and a few shell commands you'll need to get things linked together and working, but the overall process is pretty quick and painless. Even if you already have a WordPress site, it's not too hard to follow along and drop it right in.

Since I while I heard good things about nginx and wanted to use it for my Zend Framework MVC applications. I just got a Ubuntu server working after one of those days that seem to be a never ending Google search and debugging session, so I thought I'd share the outcome with you.

They show you how to install the needed packages, set up FastCGI and configure it to work with nginx and, of course, configure nginx to use the FastCGI. Included in the nginx config is a pointer to the Zend Framework's document root. Setting up the Zend Framework and creating an application isn't a part of the tutorial.

[These technologies] offer a great solution for finally getting rid of that old sloppy mod_php in Apache. Do you have the same issue where your apache instances have started to run too large? This might be the time to start to move forward.

He talks about setting up the PHP-FPM instance with a custom compile, adding in an init script (from the fpm branch on the PHP svn), installing Nginx and configuring them both to work together. He also helps you set up a sample site (and virtualhost) that will run the PHP-FPM stuff on each request.

PHP just added the FPM patch to their 5.3 branch, making it likely that PHP 5.3.3 will support the FPM SAPI. The FPM SAPI is an improved fcgi SAPI that allows for more advanced configuration than the original fcgi SAPI. One of the most useful features is process management, which makes it very useful for lightweight webservers, such as nginx, that does not handle process management of fcgi themselves.

There's only a few commands you'll need to get this new package installed and working with your local nginx install with the help of the emerge and layman tools. He also includes the configuration change you'll need to make to the nginx config file to get it working as a FastCGI module.

Recently, because of a mandatory VPS move I had an opportunity to migrate all my sites from apache to nginx. My old box was in a messy state and setting up a new box from scratch was always going to be fun. Here in this post, I will walk you through all the steps that helped me migrate seamlessly. Specially, how did I setup the new box ensuring zero downtime on the sites.

One of the keys to his transition was to have no downtime in the switch between the old and new systems (managing local vs public DNS let him test). The software is all installed via the apt-get package manager and the changes you'll need to make to the configuration files are all included, making the install as easy on you as possible.

With a clever hack utilizing Memcache, Nginx, and Drupal, we have been able to speed the delivery time of many of our major pages by 53,900% (from 8,100 msec to 15 msec, according to siege and AB benchmarks). Additional, we went from being able to handle 27 concurrent requests to being able to handle 3,334 concurrent requests (a 12,248% increase). While we performed a long series of performance optimizations, this article is focused primarily on how we managed to serve data directly from Memcached, via Nginx, without invoking PHP at all.

They describe how, by just changing out the web server to mginx and a highly tuned memcached installation, they could get huge jumps in response times. They pushed it even more when they changed the nginx configuration to directly interact with the memacahed server instead of having to rely on PHP's interface. Details on how to get this setup working and an overall view of how it works are also included in the post.

The issue was a PHP parse error which I overlooked when I added a new file. The weird thing is, I had nothing in the logs (E_ALL, display_errors is off, but all logs are enabled and I tailed them using multitail) and nginx only displayed a blank page. The errors above were in nginx's own log file.

The multitail command lets you run the "tail" command on more than one file at a time and view them split out in your console for easier reference. The full error message reads:

client closed prematurely connection, so upstream connection is closed too while sending request to upstream, client: a.a.a.a, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/tmp/.fastcgi.till/socket:", host: "localhost"