Learn More About PHP And The Web Platform!

Struggling with your web server, or to scale your PHP application to meet growing demand?

Whether you're running one server or a whole server farm; whether you're hosting on Windows Server or on Linux.

Learn from Stuart's experience with system design, delivery, support and management to help you do a better job and have an easier time.

Beneath Whitby breakwater

Many thanks to everyone who commented on my recent article and said they’d be interested in a series of posts about more server-oriented PHP topics. There were quite a few requests for a “ten point”-type article introducing the subject, so that seems to be a good place to kick things off.

Building Blocks

There are six classic ways to group and organise the servers that your web-based application runs on.

Shared Hosting

Shared hosting, like the name implies, is where you cram many different websites (normally owned by many different people) onto the same physical box. The upside is that they’re very cheap (because you’re not paying for an entire server, only a slice of one), but the downsides are that you can quickly outgrow a shared hosting server, and shared hosting servers are difficult to make really secure. Use them when you have to, but do your best to trade up to something that you can have all to yourself whenever you can.

Dedicated Server

A dedicated server is a box all to yourself. So long as you can keep the bad guys outside, you have more peace of mind when it comes to security. They cost a bit more than shared hosting, but there are many affordable solutions both in Europe and the US.

A PHP application normally needs no changes at all to move from shared hosting to a dedicated server.

What might need to change is the way you look after the installed application. Unless you go for a managed server, or you are using a server looked after by your customer, it will become your responsibility to look after the operating system installed on the server. You will be responsible for ensuring the server is patched with the latest security fixes. This can eat up quite a bit of time every week, so make sure your customer is paying for this time one way or another!

Two-Tier Architecture

When you outgrow a single server, the next step is to consider moving to a separate database server and web server, also known as a two-tier architecture. This is a popular choice because it’s quick and very painless (just order an additional box, and then move your database onto it), and it buys you the time you need to prepare for scaling up to the next architecture. Even on commodity Intel/AMD servers (I’m talking Xeons and Opterons here, not desktop CPUs!), a two-tier architecture is often enough to handle a public website for a medium-to-large organisation.

The only change a PHP application should need is to update the hostname passed to mysql_connect() et al. Consider moving any background batch jobs you have onto the database server, to further reduce the load on the web server.

It’s a good idea at this point to split your PHP application into separate publishing and admin components, so that you can move the admin website onto the database server. Splitting these up allows the admin site to function well when the main website is being hit hard, but to make it work you’ve got to start thinking about how to share data between the publisher and admin components – the data that your website publishes, and your sessions too.

Once you’ve outgrown the two tier architecture, you can add more capacity on the publishing side by moving to a web farm, and you can make your database server more resilient by upgrading to a cluster. If you don’t mind the extra complexity and the reworking involved, you can also scale further by moving to an n-tier architecture.


Be the first to leave a comment »

On Planet PHP, I see a lot of postings about PHP the language, and applications written in PHP, but not a lot about the runtime environment that PHP needs and can take advantage of. Is anyone interested in a series of posts about server architectures – not just LAMP vs WIMP vs WISP (Linux/Apache/MySQL/PHP, Windows/IIS/MySQL/PHP, and Windows/IIS/SQL Server/PHP) – but also about shared hosting vs dedicated hosting vs server farms vs active-active, active-passive clusters?

If you are interested, leave a comment on my blog to let me know. If there’s enough interest, I’ll write up a few articles about this and publish them on my blog. If there’s anything in particular you’d like to see covered, and explained in more detail, let me know!

(One of the things I do is design hosting solutions for our customers. Not the mega-solutions that folks like Rasmus gets to work on, but the smaller – and way more common – solutions needed for small to medium-size websites here in the UK).


The end-of-life announcement for PHP 4 has prompted a lot of discussion about whether PHP 5 is worth adopting at all, and even whether or not PHP 5 has hurt PHP as a whole. The technical arguments have been debated (and, alas, that will continue no matter who says what) on the Net for some time now.

What I’m not seeing are the commercial arguments to move to PHP 5 (/me points an accusing finger at the folks from Zend, with whom this discussion has been had before). Businesses will only make the move when there is something to gain from the effort, when the rewards of switching are more than the cost of doing nothing. So let’s see if we can find some reasons to chivvy them along!

Here are the arguments I’ve been making for the last 3 years to pointy-haired bosses that many technical folks ultimately have to answer to. What commercial arguments have you tried in your workplace? Post the good ones that have worked in the comments below, or on the Net on your own blogs for us all to share.

— Stu

Be the first to leave a comment »

… is this little labeling rule in the file contexts:

/usr/lib(64)?/httpd/modules/libphp5.so -- system_u:object_r:textrel_shlib_t:s0

Does this mean that RedHat is shipping a mod_php5 that isn’t compiled for relocatable code support? (See my earlier post on compiling PHP as relocatable code). If they are, according to this page by Ulrich Drepper (hey, doesn’t he work for RedHat? 🙂 ) then RedHat Enterprise Server 5’s copy of mod_php5 might be using more RAM per Apache process than necessary, which will impact scalability and capacity.

Be the first to leave a comment »

I’ve been playing around with RedHat’s newly released Enterprise Linux 5. This comes with PHP 5.1.6, which I’ve taken off my test box and replaced with a copy of PHP 4 built from source.

After installing PHP 4, the first time I tried to start up Apache, it failed with this error:

Cannot load modules/libphp4.so into server: modules/libphp4.so: cannot restore segment prot after reloc: Permission denied

This is an error message from SELinux (which is enabled by default on RHEL5). The error has been triggered because the PHP runtime code contains text relocations – a situation where the code inside the .so has to be writable in memory.

(The definitive place to look for information about text relocations and the risk they pose to the security of your server is this page from Ulrich Drepper).

The quick workaround is to run this command on your server:

chcon -t textrel_shlib_t modules/libphp4.so

This command tells SELinux to allow text relocations inside the libphp4.so Apache module. (Use the command “chcon -t usr_t modules/lib4php.so” to reverse the effect, if you need to).

There are a couple of serious downsides to this workaround. The first one is that it disables one of the protections that SELinux provides. It makes your server more vulnerable to security exploits targetted at the PHP runtime itself. The second problem is that your server uses more memory per Apache process, because each Apache process ends up with its own copy of PHP.

One fix is to recompile your copy of PHP 4 using the “–with-pic” configure option. This produces a copy of PHP that doesn’t contain text relocations. In theory (I haven’t tested this yet), it should also be able to handle more concurrent connections on a server before the server runs out of RAM. Using Apache’s ab benchmarking app, my results suggest that PHP 4 w/ “–with-pic” is about 0.7% slower – small enough not to matter for many folks.

There’s a second way to avoid text relocations – don’t compile with “–with-pic”, and use the prelink tool instead. This tool, run from the command-line, works out the text relocations once, and then writes the data back to the binaries and libraries. From my testing, this avoids the SELinux error, and performance-wise it’s about 0.1% faster than PHP w/ text relocations, and about 0.8% faster than PHP 4 w/ “–with-pic”. This approach should also bring the benefits of reduced memory usage too that go with the “–with-pic” approach, but I haven’t done any testing to confirm this.

Which approach is the best – PHP 4 w/ “–with-pic”, or using prelink? The downside of using prelink is that this approach is reported to be unsuitable for Linux installs configured to do address space randomisation. You also have to remember to re-run prelink everytime you upgrade or re-install PHP. Using PHP 4 w/ “–with-pic” avoids these issues.

Be the first to leave a comment »

Come And Work With PHP In The UK!

Posted by Stuart Herbert on March 1st, 2007 in News.

I work for Box UK, where we use PHP to craft the hugely successful Amaxus XML Content Management System, and where we use .NET to craft the double award winning clickdensity website usability toolkit. We have an impressive list of customers, and did I mention that one of our products is written in PHP? 🙂

We re expanding the team in our Cardiff city-centre office (right in the heart of Europe s youngest capital city). We re looking for exceptional people with a proven track record in designing, delivering, and managing web-based solutions to large organisations. If you re a project manager, software developer, web site designer with XSL experience, or a systems administrator, maybe we have the right opportunity for your next role.

Be the first to leave a comment »

PHP London Conference Is Packed Out

Posted by Stuart Herbert on February 23rd, 2007 in Conferences.

Mmm … the “sold out” sign on the PHP London Conference’s home page doesn’t do it justice. “Packed out” would be a much better description. There isn’t an empty seat in the house, and during the talks there are quite a few folks standing at the back or sitting on the floor.

It’s fantastic to see such a well-supported conference here in the UK. I don’t remember coming across anyone else from the UK at the PHP conferences I’ve been to overseas. Apart from Cal and Yair representing Zend, everyone else I’ve spoken to has been a developer. For all the attention that Rails has grabbed in the last twelve months, it’s great to see that interest in PHP if anything is stronger than it was a year ago.

If anyone’s interested in having a chat about the Why PHP? group, let me know. I’m sat on the back row just to the left of the main doors.


I’ll be making the bleary-eyed trek over from Cardiff on Friday morning (I’m more liking to be heading off to bed at 5am than getting out of one!) to the PHP Conference in London. If you’re going to the conference too, and you’d like to meet up afterwards (or over lunch) to talk about the Why PHP effort, please head on over to the group and let us know.

Be the first to leave a comment »

In my last post, I asked whether there was any interest in there being a resource that makes the business case for PHP. Many thanks to everyone who replied, especially David Goulden at Zend.

To turn this from an idea into reality, I’ve setup a Google group where anyone who is interested can join in, and help build this resource. Please come along with your ideas and concerns, and let’s see what we can achieve together.

I don’t know what other folks think, but I think the first step is to draw up a list of topics that the business case needs to cover. Run into a question from a customer that stops you selling your PHP solution? Let us know.


At work, we make and sell software written in a number of languages; our flagship product is written in PHP. During pre-sales, we’ve always had to handle some questions about our choice of PHP – normally from IT staff with a preference for Java or lately .NET – and we normally manage to convince the potential customer that PHP isn’t the bad choice that they’ve been led to believe.

But one of the unfortunate side-effects of Stefan Esser’s much-publicised (self publicised? 🙂 ) departure from the PHP Security Team has been an increase in the number of IT staff we’re coming across who “believe” both that open-source is inherently insecure, and that PHP in particular has incurable problems. These “beliefs” hurt ISVs trying to sell PHP-based applications into skeptical organisations.

Why isn’t there a central resource containing the answers to “Why PHP?” in a business-oriented way? Something that ISVs can refer their clients to, and it not only promotes the excellent advantages of PHP (and include success stories from vertical markets), but also include substantial rebuttals to the FUD that ISVs have to deal with during the pre-sales process.

I’m not surprised that PHP.net doesn’t contain such a resource (it’s not really the place for it, one could argue), but it’s disappointing to see that Zend doesn’t provide one. What’s good for ISVs should be good for Zend, after all, and this is an area where they could help all the ISVs that they want to sell their products to 🙂

Is there interest from other folks in having a resource like this? Or maybe working together to build such a resource?

Page 18 of 19« First...10...1516171819

This Month

May 2020
« Sep