As is mentioned on CodeIgniter.com, they've set up a survey to find out more information about how PHP are using frameworks.

The anonymous survey is very brief - just seven questions - and should take no more than five minutes or so to complete. The survey is open immediately and will remain open over the weekend.

The seven questions on the survey include questions about framework usage, sets of how you feel about different framework-related topics, what editor you usually use (and for how long), how you usually interact with Git/Github. Go and voice your opinion now!

Sébastien Thomas has a recent post to his blog shows how (with just a bit of code) you can monitor your APC cache usage on your local host.

I won't go deep into how OpCode caches work, you will find a lot of docs, just google for APC, Xcache, eAccelerator... What I can say is that APC (as other caches do) will save binary parts of your PHP code into memory and use it when you call for the same PHP function again. This way you save all the PHP file opening, parsing, etc. [...] One thing you won't come accross often on internet is How (the hell) do I know if APC is performing well ?

His answer comes in the form of code based on the APC-PHP-Monitor script. He changed it slightly to allow for use in other places, like with Nagios monitoring. A Nagois template is included to query the cache and report back a hit ratio. An example of the full cache results can be seen here complete with general cache info, hits, misses and file versus user caching stats.

Matt Farina has a new post today looking at an "underutilized gem" he's found in the offerings of the Standard PHP Library (SPL) - the SplFixedArray.

Arrays in PHP are not arrays per the typical array data type. Instead, as Matt Butcher recently pointed out arrays in PHP are similar to hashes in other languages. This can be a very important point to know when tracking down bugs in code and to programmers coming to PHP from other languages. But, what if we wanted something like a traditional array data type? Maybe something that preserved numeric order. Enter SplFixedArray.

He gives an example of using the SplFixedArray object versus the normal array variables in a simple PHP snippet showing the preservation of numbering order. He also touches on the memory consumption difference between the two, with the fixed array coming in quite a bit lower than the normal array data type (around 25% based on his basic testing). There are some catches to using it, though including incompatibility with array methods and the fact that it doesn't implement things like Iterator or Countable interfaces.

Artur Graniszewski has written up a comparison of the performance of a standard Durpal 7 installation using HipHop versus APC to handle the optimization of the application.

There have been many suggestions on improving Drupal performance, some of them recommend the use of APC module, data caching, or even compilation of the entire system through HipHop for PHP. While the first two solutions have been successfully implemented, no one was able to perform the build process. After many battles with the the compiler and the Drupal code, I present you results of the first successful translation of Drupal 7 to C++ language

He introduces the methods he used and the statistics of the platform (hardware) he tested with. He also includes the software used and compile commands used to create the compiled Drupal version. Included in the post are graphs showing CPU usage comparing the two types of testing (HipHop and APC) versus a normal PHP-based installation. It also briefly touches on concurrency levels and the different optimizations that could be made with the gcc compiler.

Chris Jones has a new post to his OTN blog today pointing to two new articles by Eli White about managing malicious website use:

The techniques Eli covers will always be applicable in one form or another. They should be a fundamental part of any website architect's bag of tricks.

The first article focuses more on methods for preventing and dealing with the inevitable spamming that comes with running a larger site. Eli's experience at Digg has provided him with recommendations like creating hurdles for spammers to get past and evaluating the content (services like Defensio or Akismet are useful for this).

The second article talks about something a bit harder to deal with - when users "game the system" and find the loopholes. His recommendations to combat this sort of abuse include rate limiting, pattern matching and leaving "traps" by tracking user usage.

In a new post to his blog Kevin Schroeder asks a simple question - why do you use PHP?

In one or two words, please comment to answer this question. Why do you use PHP?

So far, answers have included "the large community", "ease of development", "portability", "versatility" and the "power" the language offers. Leave your own comment on the post to share your thoughts with Kevin and others in the community.

Tobias Schlitt has a new post to his blog about a survey the Apache Zeta Components project is running about how developers would like to receive the libraries they use in their code.

The Apache Zeta Components project is currently discussing how to adjust the old eZ Components release process to the ASF guidelines. During this discussions, quite some ideas came up on how the process could be optimized. This brought my interest to how users of PHP libraries would actually like to obtain library code for their projects. I will publish the raw results of the survey later, so all of the PHP libraries and frameworks can benefit. So please take some minutes and fill out the form!

The survey itself is embedded in his blog post, so you can fill it out right there on the same page. It asks questions about currently used libraries, preferred install methods and deployment methods. If you'd like a more direct link, you can go here.

According to a new article on the W3Tech.com site today, around three quarters of all websites are based on PHP. They've run their own survey to gather the results about the use of several different languages like ASP.NET, Java, Ruby and, of course, PHP.

Our server-side programming language survey shows that a very remarkable 74.9% of websites use PHP, slightly increasing in the last year. ASP.NET technologies (presumably mostly C#) come in second, and a few percentages are left for Java. That's about it. The variety of programming languages used to develop websites is surprisingly small, considering that everyone and his dog develops websites these days. There is a lot of talk in the IT blogoshere about alternative languages such as Ruby and Python, but their real world usage is tiny compared to PHP.

They talk about some of the contributing factors to these numbers including the wide use of various PHP-based content management systems, the balance of high traffic versus low traffic sites and some breakdowns according to operating system, geographical area and a hint at how their survey operates to find the systems using PHP.

Paul Reinheimer has posted something to think about for both developers and those planning out projects and features - the paths the users will take through the application, not just the features they'll have available.

There's a popular turn of phrase "pave the cow paths", which was introduced to me by my friend Chris Shiflett in one of his talks. The essence (as I understand it) of paving the cow paths is that it's easier to positively encourage users to act they way they already want to, than to have them change their behaviour.

[...] You can't hope to guess all the ways users will want to interact with your products. [...] You can however release your core feature with some flexibility and mind, then watch.

He suggests four ways that you can try to figure out these paths in your applications: by logging routes not just hits, give them somewhere to talk about their experiences with the app, open it up to outside interface (like APIs) and try to open it up for multiple kinds of use, not just what trends in statistical results.

Derick Rethans has posted the third part of his series looking at the garbage collection handling in PHP (the first two parts are here: one, two). In this last part of the series, he'll look at some of the possible performance impacts the garbage collection functionality can have in your applications.

In the previous two parts of this column we have explored PHP's take on circular referenced variables and a mechanism that allows to clean up this particular problem with reference counted variable tracking. Of course, the implementation of the garbage collection mechanism in PHP 5.3 has some performance impacts. In this third and last part of the column I will cover the performance implications of the addition of this garbage collection mechanism.

He looks at the two possible places that the collection could have an impact - memory usage and run-time delays when the garbage collection routine is fired off and does its job. As before, each of the topics is accompanied by bits of code and a few graphs showing the differences between handling in PHP 5.2 and PHP 5.3 as well as a handy way to get a bit more information out of PHP (using the GC_BENCH CFLAG when compiling). ,/p>