Rasmus mentioned on IRC how he ran the [command line] tests: simply renaming the ".phpt" test files as ".php", and invoking them through the CLI webserver. The SKIPIF sections get executed, but that doesn't affect the desired outcome of testing multiple HTTP requests with different input scripts. [Here] are some quick shell scripts I put together to automate testing the OCI8 extension with valgrind.

He uses the OCI8 extension as an example, showing how to set up these scripts to enable the execution of the tests, fire up the web server and execute Valgrind to help monitor the memory of the execution.

PHP 5.4 has an built-in webserver. For local development it is not necessary to install Apache Httpd or another webserver anymore. You can just start an server from the command line. [...] To make things a little easier you can create a windows shortcut.

He shows what it looks like running in a console and steps you through the process of setting up the shortcut, giving you the flexibility to contril things like window size and buffer size.

This is a quick guide/tutorial to learning socket programming in php. Socket programming php is very similar to C. Most functions are similar in names, parameters and output. However unlike C, socket programs written in php would run the same way on any os that has php installed. So the code does not need any platform specific changes (mostly).

They start with the basics - creating a socket, connecting to a server and sending out information over the connection. They also include the code examples showing how to pull in data from the socket. Their example socket is set up to be a simplistic web server, returning data according to the standards for a normal GET request. They make a mini-server out of it, getting to to accept requests on a bound socket.

If we ignore the additional features, using uWSGI with PHP is somewhat equivalent to using the Process Manager (FPM) that ships with PHP. Just like FPM, the concept is that PHP runs inside a server dedicated to handling the processes/threads running the PHP code. This in contrast to running PHP inside of the actual webserver, like Apache's Mod_PHP, or letting the webserver handle the process management, like lighttpd typically does. In other words, you have the following chain of services: Client -> webserver -> process manager -> PHP interpreter.

He includes some information about the setup ("is it easy?") and how it's more application-based than the usual PHP setup. He also touches on two other larger concerns - is it faster than some of the alternatives and whether or not you should spend time in your day to look into it.

In a few rare cases this is not what people like, for that PHP introduced "persistent connections" of different kinds. Testing those is a bit annoying as you have to configure a webserver and ensure to hit the same instance over the course of a test and then use a load generator, probably one which can detect a failure. Additionally by having a webserver in the game there is more code being executed, which might mean an additional source for trouble while debugging. An alternative might be using FastCGI, while that adds it's own issues for such a test. To solve this for myself I, some time ago, wrote a PHP SAPI module called pconn and pushed it to github.

The extension provides a way to emulate requests by executing a script multiple times automatically, making it easier to test things that require checking against multiple things simultaneously. While the built-in webserver (PHP 5.4) can be used to test some of these things too, Johannes' extension can also be compiled to help with testing of threading in applications as well.

One of the big features arriving with PHP 5.4 is the addition of a built-in basic webserver for use in development environments. Quite a few of the other scripting languages have something like this so I'm very pleased to see it in PHP. Using a server like this makes it easy to quickly try out some scripts without needing to configure apache or really do anything much! I had to look up a few things to get started, so I thought I'd write them down for posterity.

She includes instructions on how to get the server up and running from the command line, updating the location of the document root with a command line option and using a simple "routing.php" script to act as a front controller. Changing the hostname is as simple as changing "localhost" to something else when starting the server.

The problem with the new PHP 5.4 internal web-server is that it isn't Apache. Thus it does not know anything about .htaccess. Even when you have defined your .htaccess to do authentication, the internal PHP web-server will ignore it, while in production, the authentication will be needed (if you will be running Apache, of course). Also, you need to reroute everything manually through your app_dev.php, so your URL's don't really match the way they will be on your production.

He introduces the PHP web server quickly, just showing a sample command line call to start it up and to point it at a certain PHP file as a "boostrap". With the help of his htrouter script, though, you can use "modules" similar to those in Apache. He already has the HTTP auth stuff working and more is to come.

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).

Yet another new feature to look forward to in PHP 5.4.0 - the CLI SAPI will now provide a built-in web server which is geared toward developmental purposes. It shouldn't be used in production right now.

The PHP manual has been updated with the latest on this upcoming feature:

URI requests are served from the current working directory where PHP was started, unless the -t option is used to specify an explicit document root. [...] If a PHP file is given on the command line when the web server is started it is treated as a "router" script for the web server. The script is run at the start of each HTTP request. If this script returns FALSE, then the requested resource is returned as-is. Otherwise the script's output is returned to the browser.

The PHP 5.4.x series is still in beta as of the time of this post - you can download the beta1 on the downloads section of the PHP site (or the Windows binaries).

Cherokee is a very fast, flexible and easy to configure Web Server. It supports the widespread technologies nowadays: FastCGI, SCGI, PHP, CGI, TLS and SSL encrypted connections, virtual hosts, authentication, on the fly encoding, load balancing, Apache compatible log files, and much more. This tutorial shows how you can install Cherokee on an Ubuntu 11.04 server with PHP5 support (through FastCGI) and MySQL support.

The tutorial makes use of the package manager (apt-get) to install the needed software, so don't look for complete compiling information from this process. They include a bit of the configuration of the Cherokee installation and how you enable PHP support via its interface. Screenshots of the Cherokee interface are included to help make it easier to follow along.