On the LeaseWeb Labs blog there's a continuation from a previous post about migrating your Symfony1 application over to Symfony2. In the first part of this series of posts, Stefan Koopmanschap talked about wrapping your code to make it work. In this second post, Maurtis van der Schee tackles two issues Stefan mentioned - performance problems and handling authorization/authentication.

On December 21, 2011 Stefan Koopmanschap wrote an excellent article on this blog titled "Painless (well, less painful) migration to Symfony2." [...] We were very much inspired by his passionate elucidation and we were fully convinced of the urge to start migrating to Symfony2 as soon as possible. However, he also provided us with a "A word of caution" about 2 things: performance and authentication/authorization. This might get some people worried, but not us: it challenged us to find a solution for those two open issues.

They explain why these two things are a problem and some of their solutions they've created - a .htaccess for routing and manually replicating the Symfony2 session in the Symfony1 code. Included in the post are the rewrite rules and code to make these two things happen (and a small configuration change to make them work).

Kurt Payne has a new post to his blog showing how to use register_tick_function with a callback to help benchmark and profile your application to find its pain spots.

A profiler gives you the ability to trace the performance of your code through every function call and create an overview of your system's performance over a certain time period and helps you make intelligent decisions about where to look for problems. [...] But what if you're in an environment where you can't install [the xdebug or xhprof] extension? Luckily, php has a built-in function called register_tick_function that gives you a way to hook in to every user function that's called. With this, you can write a profiler yourself.

A bit of sample code illustrates his method - it defines a "do_profile" function and assigns it with the register_tick_function call. This function generates a debug backtrace and echos out the function path it took to get to that spot (output is included). He provides code for a bit more useful profiling and points out that it could easily be graphed to help visualize the problems. Also included are a few caveats to watch out for when using this method of profiling.

In a new post to his blog Ulf Wendel has pointed out that the mysqlnd query cache plugin quickstart is posted on the docs.php.net site.

New in the PHP manual: a quickstart for the mysqlnd query cache plugin. PECL/mysqlnd_qc, the mysqlnd query cache plugin, is transparent and ease to use. But, how? Some pointers have been given in assorted presentations, here on my blog and in some, few examples from the manual. Fixed. You can now browse a quickstart to gain a quick overview.

The query cache plugin can replace the query caching MySQL does and can help with things like multiple storage options (memory, APC, Memcache, etc) and almost no changes to your application. There's also a method (mysqlnd_qc_get_query_trace_log) that comes with the plugin that gives you a "stack trace" of every query run through the MySQL interface.

Gonzalo Ayuso has a new post to his blog today looking at the performance of PHP exceptions and how it could effect your application's overall speed.

Sometimes we use exceptions to manage the flow of our scripts. I imagine that the use of exceptions must have a performance lack. Because of that I will perform a small benchmark to test the performance of one simple script throwing exceptions and without them.

His (little) benchmarking scripts are included - both looping 100000 times, one throwing an exception and the other not. The results were pretty obvious - the memory usage was about the same but the speed was about ten times faster without the exceptions (in PHP 5.3). In PHP 5.4, however, the numbers were closer as far as time to run. Obviously, unless you make super heavy use of exceptions, you're not even going to come close to something like this (micro-optimization anyone?).

On PHPMaster.com today there's a new post from Matthew Turland talking about PHP's quest for performance and some of the recent advancements that have made better performing applications even more possible.

While it's sufficient for many users, as PHP sees increased use by large sites like Wikipedia and Facebook, the ability to serve more requests on fewer servers becomes increasingly important. Some efforts have been made in this area in the last few years, both within and outside the PHP internals team. However, understanding exactly what's going on requires a bit of background both in history and concepts.

He goes through some of the origins of the PHP language (from the early days with Rasmus Lerdorf) to the fact that the PHP language itself is interpreted - complete with some of the overhead that comes with that. He also mentions various projects that have tried to compile PHP back down to C to increase performance like Roadsend, HipHop and, most recently, the HipHop virtual machine from Facebook.

On DZone.com John Esposito reminds you about another technology Facebook has introduced to the world of PHP (besides HipHop) - XHProf, a PHP profiler.

Facebook did more for PHP: they also created XHProf, a PHP profiler with a (supposedly) easy-to-use HTML interface, designed to pinpoint exactly where your bottlenecks are appearing, so that you can optimize at every stage in the pipeline. [...] If you haven't tried XHProf, you might want to look into it. Installation apparently requires a little nudging, but Nick Lewis just posted a full, practical guide to benchmarking and performance tuning your PHP and MySQL, using XHProf (as well as other techniques) -- a very nice overview of many common bottlenecks and how to open them up.

There's also a link to some Drupal 6 benchmarks that shows how it has helped that project (including both small and large improvements).

In this new post to his blog, Johannes Schlüter looks at a high-performance solution to the usual storing PHP session information via a memcache frontend with a MySQL Cluster backend.

Unfortunately even such a system [using MySQL and InnoDB tables] has limits and unfortunately replication is no good solution here to scale further as we will always need a master for writing the updated session data. By using replication we can take some load from it and we can configure a slave which can be promoted to master to keep session alive if the primary master machine fails but at some point in time we need another solution ... but, happy news, again: One doesn't have to look far as MySQL cluster will be happy to help. MySQL Cluster "is a high-availability, high-redundancy version of MySQL adapted for the distributed computing environment," as the MySQL documentation states.

He describes the setup (after pointing to this post about installing MySQL Cluster for memcache) and includes some sample code/SQL/ini settings you'll need to use to get PHP's memcached functionality to cooperate with it.

In a recent post from Learncomputer.com, there's a comparison of two PHP profilers - the PHP Quick Profiler and the one included in Xdebug.

Whether you are an experienced developer or just getting started it is important to know how to measure the performance of your scripts and applications so that you can learn to make improvements and optimizations to your code. [...] This article compares two of the most popular [profiling] solutions under free license that you can begin using today to profile your PHP applications.

They describe each of the tools - the Quick PHP Profiler acting more like a plugin (running on each page load) and Xdebug working more behind the scenes and providing cachegrind files. These files can be viewed in cachegrind tools to drill in to the badly performing aspects of your applications and find the issues.

If you need a free tool it can be difficult to find a PHP profiling tool that has all of the features you may want and the interface that you like all rolled into one. Identifying what kind of data you are looking for and what information you need from a profiling tool will allow you to choose the best solution for your needs.

In a new post to his blog Brian Swan explains why the latest versions of PHP (the 5.3.x series) are faster now on Windows than some previous versions have been. (Hint: updated technology can work wonders sometimes)

[Rasmus Lerdorf recently said at a Seattle meetup] "If you aren't running PHP 5.3 on Windows, you're lucky…because you have a 40% performance boost coming." He clarified this by saying that, with some help from Microsoft, improvements were made in PHP 5.3 that led to a 40% performance improvement of PHP on Windows. Because he didn't go into the details of why this performance boost was realized, I got questions in email the next day asking about why.

The information in a borrowed slide (from a presentation by Pierre Joye) shows what the differences between the versions are - things like the use of a more modern compiler (VC9 vs VC6), calls to the Win32 API directly and better library management.

Andrew Martin has a new post to his blog looking at a technique that could be used to help minimize some of the performance issues you could see on AWS micro instances dealing with PHP session handling. His alternative is serving them from a RAM-based disk instead.

It's rare to find a web server with slow disk I/O performance, but Amazon's EC2 micro-instances are one such example. Their EBS disk subsystem access is rated "low", and this can have a detrimental effect on HTTP throughput. [...] This leaves sessions, which can be written to a redundant and fault tolerant storage system. [...] In order to speed up the disk access, a RAM-based disk can be mounted over the session directory. This has the disadvantage of being volatile - the data is lost in case of a server reboot, or the mount point being unmounted. However if tolerable, storing sessions in RAM insulates the application from poor filesystem performance.

He mentions the two types of kernels that can be used, ramfs and tmpfs, and the specifics of using a tmpfs filesystem to implement the technique (complete with command line calls to make it happen).