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!

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.

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.

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.

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 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.

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.

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.

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.

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>]]> Mon, 13 Sep 2010 11:22:42 -0500