In a new post todayStuart Herbert asks the question "is it possible to secure a shared server with PHP and FastCGI installed on it?" His answer follows...
The challenge with securing a shared hosting server is how to secure the website from attack both from the outside and from the inside. PHP has built-in features to help, but ultimately it's the wrong place to address the problem. [...] Before we can look at performance, the first question is: how exactly do we get PHP and FastCGI running as different users on the one web server in the first place?
He follows through on this, giving a little mini-tutorial on getting the environment installed on an Apache web server. He includes some benchmarks on the difference between using the Apache 1.3.x series and Apache 2 (generated using the ab benchmarking tool).
On his blog recently Felix De Vliegher has posted about work he's done to gather some stats and great some data about how his PHP scripts are working based on a little statistical analysis.
Lately I've been interested in applying static analysis to PHP projects. Static analysis is the process of analysing software code - in our case PHP source code -, without actually executing the (compiled) result of the source code you're analysing.
He mentions some types of analysis and some of the tools that can be used to measure it. He also talks about issues it can help with (like the potential for harm if a part of code is changed) and a pointer to the Pixy software he used to generate the statistics (and images like this).
On the Developer Tutorials blog, Akash Mehta has posted an introduction to working with command-line PHP scripts and cron jobs for site automation.
Scheduled tasks are a fairly common feature in modern web applications. From cleaning out caches every 24 hours to checking subscription periods and even generating reports, more web applications live by the clock than ever before. But how do we schedule the execution of a PHP script on the server side?
He shows the two key things to getting it working - an example of a command-line call to a PHP script (executed through his /usr/bin/php) and an example of a line from a crontab showing how to execute the script at midnight every day.
Finishing off their series on destructors in PHP5 applications today, DevShed has posted this new tutorial showing how to manually run the destructors of your class (in case there's ever a need).
In this final tutorial of the series I'm going to show you how to manually trigger a destructor, and in addition you'll learn how to emulate the behavior of this magic method when using PHP 4.
They not only talk about how to call the destructor manually but they also show how to call multiple destructors at the same time to destroy lots of objects at once. And, as promised, they include a method for being able to use a destructor-like bit of functionality in a PHP4 app as well.
Sebastian Bergmannpoints out a new feature that PHPUnit (the popular PHP unit testing tool) now has - parallel_test_execution allowing for each test to execute on a separate PHP process.
The advantages of this include full test isolation and the fact that a test can now cause a PHP fatal error or even a segmentation fault of the PHP interpreter without interrupting the test execution.
He does mention, however, that it can cause a bit more overhead for larger testing suites since it needs to create a new process (complete with memory usage) for each running test. There are also coding issues that could be thrown off by this option (he gives an example of an inheritance issue with eZ Components).
He also notes some of his thoughts on how to control/configure the process (like in a configuration file) and via an "@isolated" notation to make it easy to do it dynamically.
On AlternateInterior.com, there's the start of something that could be used to speed up the execution of your app - multi-threading in PHP.
PHP does not have threading anywhere in its massive core. We can, however, fake it by relying on the underlying operating system's multitasking abilities instead of PHP. This article will show you how.
PHP has no built in support for threading. But there can still be times when you've got lengthy code to run and idle CPU cycles you'd like to capitalize on. We can treat child processes as threads.
He (Brian Bosh) uses the example of executing five other PHP scripts inside of another through the use of a multi-threading class he's developed. Included is the code for both the class and the example code to use it.
phpaddiction has posted part three of its URL Rewriting tutorial series today - the creation of the "C" (Controller) in MVC.
In the final part of this series, I will build a functional modular front controller that can be easily adapted to small projects. It is basically the "C" in MVC for a simple MVC framework. If you haven't read the first two articles I recommend that you read over them first. Url Routing with PHP - Part One and Url Routing with PHP - Part Two.
They start with the base created before (with some slight modifications) and build up the dispatcher to handle their new requests and the controller to respond. In their example, when the Controller is called, it runs the execute() method and, based on the input, either calls another function or returns an error if it doesn't exist.
Lee Underwood shares a handy bit of software in this quick article on Developer.com - a GUI program that helps you execute your PHP scripts on Windows without the setup time of something like XAMPP.
There's no need to install a server and PHP and then try to coordinate them in order to get them to work together. Script GUI comes in one compact package. It includes a server, which is only available to the built-in browser and is a nice security feature. In addition, it supports CGI, virtual hosts, directory aliases, custom error documents and understands most commands in .htaccess files.
He tell how it works (pretty much just install and go) and how it can be configured to work with virtual hosts. Best of all, it already comes with the latest version of PHP for Windows and can interface with several of the popular databases out there.
On the Drupal site, there's a handy article instructing you on getting the most performance out of your server for the Drupal software.
The performance of your Drupal site is dependent on three main factors: the goals of your site, the resource demands of your site traffic, and the system performance and configuration of underlying technologies.
They seperate it out into three different sections - setting out your performance goals, analysing your site for current traffic/resource consumption, and the actual implementation of the performance settings. They give a few steps here to follow to check what your server is currently using and some links to other tips on tuning the various pieces of the puzzle.
One thing that they mention that's worth repeating to any and all web developers out there: "Apache is bandwidth limited, PHP is CPU limited, and MySQL is memory limited and disk I/O bound".
Builder.com.au has this new article posted today with a good guide for working with the command-line version of PHP.
PHP is most often used in combination with a Web server, to dynamically generate Web site pages. However, this Web server interface isn't the only way to use PHP, because the PHP distribution also includes a command-line interface which can be used to run PHP programs at the command prompt, much like Perl or bash.
This document will introduce you to PHP's command-line interface (CLI), showing you how to interact with PHP programs at the command prompt.
They start off with basics, things like making it executable and creation of a simple program. They then move into taking in arguments on the command line and some of the options you can pass in too. Lastly, they demonstrate the interactive mode that the PHP CLI has to allow you to interpret PHP code on the fly...
