Tag: php

What is the best PHP accelerator to use?

Posted by Robert Gentel – February 1, 2009

Well let me go ahead and tell you. Of course, this is all just my opinion and your milage may vary.

First, I will discuss the role of PHP accelerators (Opcode cache) in server tuning and scalability briefly. These tools will not enable your server to handle much more traffic in most scenarios. In some, the additional overhead of the PHP caching will even cause more load, others gain a marginal improvement by getting requests served a bit more quickly and having fewer concurrent connections. But they will not significantly raise your concurrent user limitations, as in a LAMP stack your bottleneck is usually at the database.

The way these PHP accelerators work is by caching the compiled bytecode of your human-readable PHP. Normally, your PHP code is compiled and then executed at runtime but these tools cache the compiled code, saving the expense of compiling it and thusly generally save you a bit of CPU at the cost of some increased memory usage.

So what PHP acceleration can do is make your PHP execute more quickly, and execute in roughly half the time. But it’s important to understand just what it’s accelerating, because your PHP execution is typically not what most influences the perception of speed to the user. To the user it’s a combination of page generation time, network latency, and page rendering time. These php caching tools may influence the page generation time but as I’ve already said, the database is usually the key there, and it’s both the bottleneck for concurrent users as well as the bulk of the page generation in typical setups. To make the biggest difference there you need good database design and data object caching with something like memcached, but here we’ll go over the options to improve your PHP execution times.

Alternative PHP Cache – http://pecl.php.net/package/APC

eAccelerator – http://eaccelerator.net/

XCache – http://xcache.lighttpd.net/

Zend Platform – http://www.zend.com/products/platform

ionCube PHP Accelerator – http://www.php-accelerator.co.uk/

Turck MMCache – http://turck-mmcache.sourceforge.net/index_old.html

On the able2know Q&A site we have used Zend and Turck MMCache in the past, with favorable results, but I am on a scalability and performance crusade here, and wanted to pick out the best of the current crop. Turck MMCache has not been actively developed for a while now, and is not a viable option for us to use in production, so that one’s out. I did the research into a variety of benchmarks (see chart), and with few exceptions the main competitors perform close enough to each other to make the performance differences less of a deal-killer in a selection between them. Simply put, the marginal performance gains you may acheive by selecting one over the other may be outweighted by differences in things like price, or how actively the code is being developed.

So I narrowed the selection down to XCache, APC and Zend. Zend does much more than PHP caching, and may be the right choice for others but they are a proprietary option that you must pay for, and that doesn’t justify the cost difference through performance gain as a PHP accelerator. XCache and APC are developed by well known programmers in the open source world, being the developers of lighttpd and PHP itself respectively. But between the two I am opting to use APC on able2know, as it is a pecl extension maintained by the maintainers of PHP itself (including the creator of PHP) and is reportedly going to become a core part of PHP 6.

So at least for me:

The best PHP accelerator to use is APC.

PHP Namespaces

Posted by Nick Ashley – October 26, 2008

I have been seeing alot of complaining lately regarding PHP namespaces, and I thought I would chime in with my (often opposing) views. First off, let me explain the issue.

The new version of PHP will have a new feature, called namespaces. (I wrote about it in my post”PHP 5.3 Feature Preview“. This is a great featured, and one that the community as a whole is excited about. So what is the problem, then?

Well initially PHP was going to use the standard “::” syntax to invoke the namespace. For example:


namespace Foo;
   function bar() {
      echo "Namespace Foo";
   }
   Foo::bar();

However, this became a problem for the parsing engine, as it is the same way to call a static function.

class Foo{
   static function bar(){
      echo "Class Foo";
   }
}
Foo::bar();

So instead, PHP changed the syntax to a blackslash. So now, in the first example, you have ‘Foo\bar();’ while in the second, you still have ‘Foo::bar();’ Seems reasonable to me (and the PHP core members) but not to some.

For example, Ninh complains on his blog that if you put the invocation in double quotes, it will interpret things like “\t” as a tab, and that you have to use 2 backslashes. I really don’t see this being a problem. First off, why on earth would you use double quotes? There are no variables or single quotes being used in the string, so one should be using single quotes anyways. That is just good programming practice.

Even if you do use double quotes, there is a tried and true, standard solution to escape the backslash character. It is so obiquitous, that Ninh didn’t have to learn how to use it, he already knew about it, yet is still complaining. His problem with this method? “It looks like crap”. I’m sorry, I though we were using logic to code web applications, not painting a picture. And even at that, why does “::” look awesome, but “\\” look like crap? I don’t get it.

My favorite quote if from the very end of his post. He claims “Last time I checked, the world wasn’t filled with scrawny developers that would come crying to their mommies after getting their first facepalm of ‘AmbiguousInvocationError’.” And yet he is crying to his mommy (or rather, the blogosphere) because if he uses double quotes (which he doesn’t have to) then he has to escape the backslash character (a standard practice) and that’s “ugly”.

So what are your thoughts? Maybe I’m crazy, and this is a huge deal. I just don’t see it.

PHP 5.3 Feature Preview

Posted by Nick Ashley – August 13, 2008

Earlier this month the PHP development team released an alpha version of the PHP platform (Read the Official Announcement). Of course there are many bug fixes, improvements, and new features. Here is a quick breakdown of the new features I am most excited for:

  • Namespaces – Finally! No longer do you have to worry about variable, function, or class names in the global scope interfering with other code libraries you may be using. A namespace essentially gives you your own personal global namespace, which you get to define. This means if you create a class called ‘user’, you can use someone else’s codebase even if they have a ‘user’ class as well.  Other languages such as C++ have had this feature for years, so its great to finally have it available to PHP. This may convince some that PHP is a viable solution in more huge, enterprise level codebases.
  • Late Static Binding – this is for those hardcore OOP coders. What this allows you to do, is reference an objects type (class name) from a function that is only available via inheritance. Its a confusing concept, but can prove useful in some situations. For a better example, see the Late Static Bindings Manual (procedural programmers need not apply).
  • Lambda Functions and Closures – Lambda functions are essentially anonymous, throw away functions. They can be useful if you want to use a simple function when you are already inside a function. Without Lambda functions, it would need to be defined elsewhere. However in some cases this can be hard to follow when reading the code, and seems wasteful when you only need to use the function once. A perfect use-case for Lambda functions is when they are defined for callbacks for other functions, such as array_walk(), or preg_replace_callback(). With Lambda functions, you can assign the function to a variable. Javascript programmers will recognize these as anonymous functions, as they are something many javascript programmers use heavily.

These are all very welcome additions, and I can’t wait till the stable version is out. The current roadmap estimates a stable version will be available by mid-October. Kudos, PHP Development team, keep up the good work!

Database driven radio buttons

Posted by Nick Ashley – July 10, 2007

So I had a great post explaining how to get the value of a radio button if they are dynamically created (such as through a database query) and unforunatly it was lost. Just today I noticed that it was somehow changed to another post about breadcrumbs. I’d like to think I will come back and create another quality post on how to get values of dynamically created, database driven radio buttons.. but until then, here is the short version:

Basically what you are going to want to do it assign a loop counter variable, and add it to the end of each radio button name:


$loopCount = 0;
while($result = mysql_fetch_array($query))
{
   echo "$result[name]";
   $loopCount++;
}

Now when we are error checking values, we can start at 0 and loop until the variable no longer exists. 


while($_POST['radioSet' . $i])
{
  //Error check value, post to database, whatever needs to be done
}

Here you can see, regardless of how many “radioSet” inputs we have, our error checker will get them all. In this example I only gave one radioButton for each input name. Of course for each loop, you can have multiple numbers of inputs. Also, you can give each element an ID using a similar naming tactic, which would allow you to control them all with javascript using document.getElementById.