Some quick PHP performance stats: suPHP vs prefork+mod_php vs itk+mod_php

I have been doing lots of research on how to properly secure PHP on a shared server, especially with regards to finding the best way to sandbox users. On stock apache installations, the apache user must have access to web content in order to serve it which has the unfortunate side effect that every user on the shared hosting server can read the files of every other user.

The solution to them is "sandboxing" them, or in other words having Apache serve each user's web files as that user. I will post a tutorial relatively soon detailing how to do so (along with configuring many other services) but in the mean time here are some benchmarks:

prefork: 2.720166 seconds
suphp: 13.621006 seconds
itk: 4.263002 seconds

These benchmarks were generated using the "ab" benchmark included with the httpd server. They represent the time it took to load the front page of my blog 200 times:
ab -c 1 -n 200
prefork is the standard apache MPM working with mod_php. It's the fastest, but for the reasons outlined above also the most insecure. suPHP tackles the problem by using a SUID executable and running PHP under CGI, but it is extremely slow - even for this modest drupal site, it is just over 5x slower than stock. I compiled the ITK MPM for Apache which also offers the feature of running files under different users but it is based on Prefork and uses mod_php. The performance is still worse (2x slower) than stock, but much better than suPHP.


The sequel to my Ubercart i18n adventures

It has been a while since I last wrote about Ubercart, but I'm still working on some multi-lingual stores for clients. I have opted for disabling the stock Catalog module and using Views instead since Views is so much more flexible and easier to theme. I have a very simple setup; some terms in a vocabulary that is localized per-term, and then a custom View that takes a term name as an argument and returns nodes belonging to that term and displays them in a nicely themed grid.

Recently, I ran into an irritating issue where the View would return results from the wrong language if two languages had the same term name. After hours of investigating (and learning all about how to implement View handlers and plugins), it seems that the stock taxonomy term argument validator for Views cannot differentiate between terms of the same name in different languages. So if multiple languages contain the term "Stewart Adam" for example, the view will just returns nodes for whichever term (and therefore language) comes first in the database query. To be fair, the i18n module adds the "language" column to the term_data table so it's not really View's fault... Nonetheless, I was surprised that the i18n module had not already corrected this issue.

I've just reported Drupal issue #832100, Taxonomy term argument validator should not validate terms defined in other languages that includes a fix to the problem by limiting query for term names to terms within the active language. It's not the greatest way to go about solving it since it essentially just copies the original validator and makes two tiny modifications in the SQL query, but it's better then modifying the View module directly.


XMLmind's XML Editor

DocBook is a great tool for any documentation writer, but it can be a real pain to get adjusted to. I had decided to use it for the fwbackups 1.43.2 user guide the end result was great (less a few spelling mistakes), but coding it by hand took a long time and isn't something I would want to do again

I have been using XMLmind's XML Editor to rewrite the documentation for fwbackups 1.43.3 in DocBook 5 and it's been great. It has a WYSIWYG interface and although the program has a small learning curve, once I got used to the hotkeys my productivity went way up. Version 4.6.0 (released about two weeks ago) also includes a new Link tool can be enabled in the Preferences (under General > Features) that is excellent for creating cross-section links in your documents. After giving a section an xml:id name in the Attributes section, highlight a piece of text and select Edit > Add or Change Link... from the menu. All of the document's xml:ids for will be listed and selecting one will create the link automatically.

The license for the personal edition license allows XMLmind's XML editor to be used to write documents for any open source software (as defined by the OSI) - if you need a quick way to write great looking documentation, consider paying XMLmind's website a visit.


Random thought

In any of my future classes related to operating systems, I want to try saying "sudo" instead of "please" and see how many people get it :P

I'll keep you updated.