Matthew Turland has this new blog post looking at some benchmarks he's generated for a group of mainstream PHP HTTP clients:

One of the interesting bits of research that I've done is benchmarking various mainstream PHP HTTP clients. Of course, we all know that there are lies, damned lies, statistics, and benchmarks, so take these with a grain of salt.

He ran them on his Sony Viao on Ubuntu with a stock PHP5 package. The tested packages were the pecl_http extension, the streams http wrapper, curl integration into PHP 5, PEAR::HTTP Client class and the Zend_Http_Client component. He includes the code he used for both a basic request and for something slightly more complex (posting form data). He used the XDebug and KCachegrind combination to produce the results.

Sander van de Graaf has put together a new post for his blog today that looks at a few ways you can optimize your Zend Framework application.

In the process we're also porting all of our applications to Zend Framework (talking about migrations ;)). After finishing our first project, and moving it over the performance testing phase and all, we encountered quite a few issues. [...] While we don't have the visitor numbers he has for this particular project, we also have a lot less hardware to work with. Let me emphasize that. We have a lot less hardware to work with.

So, to squeeze the most out of their current setup, Sander worked through the process to see how their machine perform and a dew things that they did to give them a bit more of a boost. There's some general tips (like Apache settings) and some more PHP and Zend Framework specific suggestions.

On the Hurricane Software website they've done a comparison between PHP and Python judging them based on things like feature set, community and documentation.

What does it take to state one language better than other? One answer can be flexibility, development friendly, licensing policy (open source or commercial), community, portability, dynamic typing, support for variable number of function arguments and ability to freeze live objects in a string representation. Documentation of course is a major player when you choose a language because you still have to sharpen your skill and you haven't worked on that particular language yet.

They go through a list of the prominent features of each language as well as some basic benchmarks for mathematical operations like finding primes below 10000 and looping with a bit of calculation. They compare the two languages' speed of execution, speed of writing, ease of setup and portability.

You can also listen to the report via the in-page player.

In a recent post to his blog Rubayeet Islam compared the more traditional way of running a query in MySQL versus a prepared statement with the MySQLi extension.

Consider a PHP-MySQL application where the information of 1000 users is being retrieved from the database by running a for loop [...] in each iteration, the first thing the MySQL engine does is to parse the query for syntax check. Then it sets up the query and runs it. Since the query remains unchanged during each iteration(except for the value of user_id), parsing the the query each time is definitely an overhead. In such cases use of prepared statements is most convenient.

He explains what prepared statements are and some of the advantages around them and includes some benchmarking examples to show the differences - about a five second jump in favor of MySQLi.

In a recent post to his blog Patrick Allaert takes a look at benchmarking what Zend Platform has to offer against its open source brothers, Xdebug and APC.

The benchmark has been realized on an Intel Core2 Duo CPU T7500 @ 2.20GHz with 2Gb of RAM running Gentoo with a 2.6.25-r7 linux kernel. ab, the Apache Benchmark tool, has been used for the benchmark with 3000 requests and three concurrency modes: -c1, -c5 and -c50 which represents respectively 1, 5 and 50 simultaneous users. The application tested is eZ Publish 4.0.1 with default configuration using the "plain_site" example.

He tested with a number of different PHP installations including a base install of PHP 5.2.6, one including APC, another with APC+Xdebug and others with the Zend Platform. The resulting stats are included as well as a graph showing their relationships to each other. The installs using the bytecode caching came out on top (obviously) with the APC installations being much faster than the accelerated Zend Platform.

Richard Thomas has put together a quick listing of resources, tips and articles for the Solar PHP framework.

Here is a quick reference list to a ton of Solar Framework Articles around the web.

He's broken it up into Tutorials (including a few from our own blog), Tips and other random content.

Recently on his blog Yannick has done some benchmarking comparing mbstring and iconv in PHP 5.2.4 release.

Following up on my previous post about the differences between the mbstring and iconv international characters libraries (which resulted in a tentative conclusion that nobody knew anything about those differences), and particularly the comments by Nicola, we have combined forces (mostly efforts from Nicola, actually) to provide you with a little benchmarking, if that can help you decide.

His code for the test script is included (for you to gather your own results) and a full listing of his results comparing the effects of possible caching, running up to ten executions. You can download the text file that he ran the script on here.

In a new article to his blog, Ryan Campbell has expressed some concerns in the amounts of memory that some of the object oriented practices in PHP are using these days.

It's hard to imagine pushing the limits of object oriented PHP so far that your web servers choke, but the truth is those limits are reached faster than you think. [...] While replacing objects with arrays when possible makes things a little better, the most performance friendly approach involves appending strings. For your convenience, we've run some tests that measure page execution times and memory usage to create the following guideline to help you plan out what areas of your code may have to break away from an object oriented nature.

He shares some benchmarks of the memory use for different variable types - strings, arrays and objects - giving load times and the amounts of memory used. He mentions three workarounds that could help (unset, static methods and paging) reduce the memory consumption of your script.

On the PHP::Impact blog there's a recent post that details a statistic Paul Jones found with the Zend Framework's performance - a drop in the response time of the front controller between the 1.0 and 1.5 releases.

The most important factor in making a Web application fast is its basic design. You must also know what kinds of processing your framework is doing, and what its bottlenecks are. The best way to find the performance bottlenecks is to monitor the performance counters and to have a thorough understanding of the framework your application is using.

Federico runs some benchmarks of his own (using the Apache benchmarking tool, ab) both with a default "base app" and with a more optimized "take out what you don't need" version.

Benjamin Eberlei has posted some benchmarks he's put together as a part of his attempts to optimize his Zend Framework application.

I haven't changed great parts of the code or anything, I just benchmarked how different global include strategies affect the overall performance of my blog software written with help of the ZF. The following include strategies were tested (I've used the Zend Framework 1.6 RC2 package for all of them): Zend_Loader_Autoload (default and swapped include paths), ZF 1.6 RC2 stripped of require_onces and stripped of require_onces/no autoload and all files directly included.

He ran the tests both with and without APC enabled with a larger difference between the stats without it turned on for each of the four tests.