Stuart Herbert On PHP

Gearman is a lightweight, high-performance solution for farming out processing work from one machine to another. I’m currently looking at using Gearman as a key part of the architecture of a new web API that I’m doing the R&D for. (I’ll go into why I need something like this, and why I’ve chosen Gearman in particular, another day).

Getting Gearman up and running on Ubuntu 9.10 (Karmic Koala) is very straight-forward and only takes a few minutes, but oddly not clearly documented on Gearman’s own wiki at the time of writing.

1. Add “ppa:gearman-developers/ppa” as a software source.
2. sudo apt-get install gearman-job-server
3. sudo apt-get install libgearman-dev
4. sudo apt-get install uuid-dev
5. pecl install “channel://pecl.php.net/gearman-0.6.0″
6. Add a gearman.ini to /etc/php5/conf.d, with “extension=gearman.so” as the contents
7. sudo /etc/init.d/apache2 restart
8. Check phpinfo() to make sure gearman extension loaded

You’ll find that the gearmand process is already up and running, and listening on port 4730 on localhost. All you need to do now is to write some code to take advantage of it

A recent El Reg article about trends in the PHP community caught my eye yesterday morning. The headline is about Zend’s depressing statistic that the majority of PHP developers do their development on Windows these days (which I’m assured by Marco is old news) … and that’s worth talking about at some point, but it isn’t what interested me the most.

As reported by El Reg, Zend’s survey results show that “seventy per cent use Zend’s Studio or Eclipse PHP Developer Tools, while 18 per cent use Vim.”

This isn’t a case of Zend making wild claims though, just less than full reporting by El Reg this time around. Zend’s own press release make it crystal clear that these are the results of a survey conducted across the Zend Framework developer community; most likely (but not directly attributed) the 2009 survey. That they haven’t released the breakdown for Zend Studio vs Eclipse PDT is perhaps telling, but still, the real headline should be:

In its own community, Zend is being very successful at convincing its community members to use multiple Zend products.

Zend’s “full-stack” strategy is starting to yield results, and it looks like Zend Framework might have been the missing component that held back their earlier attempts. The whole stack has been refreshed, true (Zend Studio now runs on Eclipse, Zend Core has folded into Zend Platform, which itself has the new and far-better-architected Zend Server positioned below it), but with Zend Framework, Zend are (imho) now able to appeal to the sort of developer communities who are willing to pay Zend’s prices. And Zend Framework is finally a product that third parties can make money from, making Zend a little more relevant in the daily lives of your average PHP developer. (I’m a great believer that a key component of all really successful products is that third parties can make money off it, not just the original creator / provider).

Now, if only Zend had an outreach programme for making Zend Server suited both technically and commercially for ISPs like where I work to consider adopting for their shared hosting and VPS customers …

By now, you might have heard the details of HipHop, Facebook’s PHP-to-C++ convertor that was announced yesterday. Like most of you, I’m eagerly awaiting the release of the code so that I can play with it and learn in detail what it can do and what it can’t. For now, Marco’s post seems to have the most technical information in it so far.

I’m with Sebastian on this one. Whether or not you think Facebook’s HipHop is relevant to you, I think they deserve credit for having shared their particular solution with the wider community. (They’ll get extra credit when they actually release some code ) After all, they’ve built on top of open-source in the first place; giving something back to the community is part and parcel of being a good member of the community.

How many of you earn your living from open-source, but have never contributed anything back?

But that isn’t really what I want to blog about today.

I’ve been following the chat on Twitter about HipHop, and I think all the nay sayers have been overlooking an important point. HipHop has the potential to reduce the amount of power consumed in running a website. And surely that can only be a good thing for all of us?

If you don’t run your own servers in a data centre (for example you use a virtual server, or host on a shared hosting solution), then perhaps you might not be aware that the power required by each server in a rack is often a major factor in the overall cost of running the servers. Whether or not you believe in climate change, energy prices are on the rise. Whether or not you believe in peak oil, oil and natural gas supply issues are forecast to push energy prices up further. Taking steps to get more work done per unit of power consumed has been the focus of hardware manufacturers for several years now. Isn’t it time it also was the focus of the software community too?

CPU usage is only one aspect of the total power consumed by a server in a rack, but in my experience people tend to add more servers to their solution primarily because they need more CPUs running their web servers to handle more traffic. A reduction in the number of CPUs required will translate into a reduction of the number of servers required … which means a reduction in the amount of energy being consumed.

How can that not be a good thing, if it can be achieved?

I know the answer will be that PHP apps are not CPU-bound, that they spend much of their time waiting for results from the database. That might be true if you’re measuring a PHP app from the point of view of elapsed time, but what if you’re measuring the PHP app in terms of CPU cycles consumed? Every single PHP script has to run on a CPU, and has to get to the point where it’s sat waiting for the database. If HipHop means that each PHP script uses less CPU to get to the same point, that has to be a step in the right direction.

Until we can play with HipHop ourselves, it’s impossible to say whether it saves enough CPU cycles to allow us to use less CPUs and therefore less servers. Remember, you’ve still got the overhead of your operating system and web server to factor into the equation. And then there’s the energy cost of compiling your code in the first place during development; for seldom-visited websites, HipHop may increase overall energy requirements.

But it sure is nice to hope, isn’t it?

Last year, I ran a series of polls via Twitter to try and learn a bit more about your plans to move to PHP 5.3, and whether or not you actually followed through. A huge thank you to everyone who voted!

I’m not talking at any conferences this year, so I’ve published the planned PHP 5.3 adoption talk online for anyone who’s interested in what the PHP user community told us via these polls. As well as the raw data, I’ve included an analysis of what the data might mean, and some talking points about what the PHP Group might want to do differently when PHP 6 (or PHP 5.4 if there is one) is released.

You can find the talk online at Slideshare, along with all of my older talks. I hope you find it useful and informative.

Whether you’re looking at your own code before (or after!) you have shipped it, or you’re picking up someone else’s code after they have shipped it, tracking down and fixing bugs is a fundamental part of programming. If you know the code well, perhaps you can make an intuitive leap to immediately jump to where the bug is. But how do you go about tracking down a bug when intuition doesn’t help?

The nature of all code is that larger systems are built from smaller underlying systems and components. They in turn are also constructed from smaller components. The bug you are tracking down will have a cause in one of these systems, and will have symptoms that are visible in other systems. The remaining systems work fine (as far as the bug you’re looking for is concerned), and you can use this to quickly and reliably find where the bug is.

Divide your larger systems down into smaller systems at logical points, such as different server stacks, APIs, major interfaces, classes, methods and if necessary individual lines of code. Test both sides of the divide, with your tests focusing on the data that crosses the divide. If one side works as expected, the bug is not in there, and you can eliminate that side from further testing. Continue testing the remaining systems and components, which you have now isolated, by dividing those up into smaller systems and components. Keep going until you’ve reached the smallest testable system, component, unit, or lines of code that show the fault. Congratulations: you have isolated the fault.

Apart from being a strategy that allows you to work on code you’ve never seen before, this approach also has the advantage that it is evidence-based. This approach eliminates guess work, and it forces developers’ assumptions about how their code actually works in practice to be challenged. The data never lies, but be aware that it can be mis-interpreted!

The approach is iterative, and you’ll find that you’ll often go back and forth between your code and your tests, making your code easier to test and your tests have clearer and more targeted test domains and results. Fix the tests that are relevant to the bug you are tracking down, and make a list of any other issues you find along the way for you to come back and address at a later date. Stay on target, and park potential tangents and distractions for another time.

Although this sounds like a slow process when described on paper, with practice it can be executed at high speed during an emergency situation. However, the need to restore service in a timely manner isn’t always compatible with this approach, and you’re normally better off returning to your test environment where you can study the fault without inconveniencing your customers any further.