On the Tideways.com blog there's a tutorial talking about the "unknown performance bottleneck" that can be caused by PHP's own session garbage collection. This garbage collection happens when sessions expire and they need to be removed from the current set/data source.

Here is one performance setting in your PHP configuration you probably haven't thought about much before: How often does PHP perform random garbage collection of outdated session data in your application? Did you know that because of the shared nothing architecture PHP randomly cleans old session data whenever session_start() is called? An operation that is not necessarily cheap.

It's his general advice to avoid PHP's random garbage collection (it happens one in every 1000 requests, randomly) and opt for a more consistent method using background scripts. He gives an example using the Laravel framework and it's modified session garbage collection happening every 50th request (making use of the Symfony Finder component). He points out the problem with its implementation and the negative impact it could have on large, highly used applications. They share some of their own statistics and how to change this default (modifying the lottery option and making a custom "cleanup" command).

In his latest post Anthony Ferrara looks at a recent change in the Composer dependency management tool involving a major speed boost, just from disabling the garbage collection.

If you've been following the news, you'll have noticed that yesterday Composer got a bit of a speed boost. And by "bit of a speed boost", we're talking between 50% and 90% speed increase depending on the complexity of the dependencies. But how did the fix work? And should you make the same sort of change to your projects? For those of you who want the TL/DR answer: the answer is no you shouldn't.

He talks about what the actual (one line) change was that sped things up but goes on to talk about why doing this isn't necessarily a good thing. He covers how PHP handles variables internally, how it relates to "pointers" and the copy-on-write functionality. He includes code snippets and gives an overview of how each would be handled by the interpreter. Unfortunately, the way PHP handles things, deleting a variable only removes variable reference, not the value, but does decrement the reference count for it. When that hits 0, garbage collection kicks in and removes associated values too.

He talks about a few other kinds of garbage collection (the reference count method is just one of them) and circles back around to how this relates to Composer's functionality. He points out the number of objects created during the dependency resolution process and what can happen when the root buffer, populated with all of these objects, gets too full (hint: garbage collection). He finishes the post talking about how, in Composer's case, the garbage collection change yielded the performance impact it did, but doesn't suggest it for every project. He also makes a few suggestions as to things that could be done to improve PHP's garbage collection handling.

Joshua Thijssen has put together a new post with details about garbage collection in PHP and a "nice bug/feature/whatsmathing" he found related to it and its performance.

I was playing around with writing a daemon and if you have any experience writing daemons (in any language), there are a few rules you have to live by. For instance, setting your effective uid and gid to a non-privileged user (in case you needed to do some privileged initialization, like opening a socket on a tcp port < 1024), setting the process as a group leader with posix_setsid(), and redirecting stdio file descriptions. And here something went wrong which took a while to find and fix..

He was creating a daemon and the script would just exit without a warning and not continue running. He narrowed down the issue to a few lines (with fopen and fclose) and went to debug it with strace to really see what was happening. He found some unexpected calls in the stack trace and, after some more digging, finally figured out it was a problem of both scope and cleanup that was resulting in the extra calls.

If you've been working with PHP for any length of time, you probably have wondered what happens to everything you've created when your script's execution ends. Well, in this new post from PHPMaster.com PHP's garbage handling functionality.

It’s interesting how just a few years can make a difference in the names that are given to things. If this were to come up today, it would probably be called PHP Recycling Options, because rather than picking things up and throwing them into a landfill where they’ll never be seen again, we are really talking about grabbing things whose use has passed and setting them up to be useful again. But, recycling wasn’t le petit Cherie of society back when the idea was developed and so this task was given the vulgar name of ‘Garbage Collection’. What can we do but follow what history and common usage have given us?

They talk about a few different kinds of data that the garbage collection system cleans up including the program-generated information and the three tiered system the languages for cleanup:

• First Level - End of Scope
• Second Level - Reference Counting
• Third Level - Formal Garbage Collection

Chris Hartjes ran into an issue with hit unit tests where PHPUnit was throwing an "aborted" error no matter what tests were run. Thankfully, in this new post, he shares a solution.

That was a pretty annoying bug. I never did find out what the problem was as I moved onto other problems and chalked that error up to some undiagnosed weirdness on that particular server. From time to time I would get asked on Twitter if I had ever solved the problem. My answer was always "no, and if you do solve it please let met know how you fixed it." Today, my friends, was the day.

Based on a response from Demian Katz, he was able to get around the issue with flag set on the PHPUnit command line - "-dzend.enable_gc=0". Apparently the issue has to do with garbage collection and has been a known issue since the beginning of 2011.

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>

Derick Rethans is republishing an article series he wrote (originally for php|architect) about the garbage collection that is included with the PHP 5.3 releases. He kicks off the series with this first post introducing internal variable handling.

Before we start with the intricate details of PHP's new GC engine I will explain why it is actually needed. This, combined with an introduction how PHP deals with variables in general is explained in this first part of the column. The second part will cover the solution and some notes on the GC mechanism itself, and the third part covers some implications of the GC mechanism, as well as some benchmarks. But now first on to the introduction.

He introduces the concept of a "zval" - the container PHP uses internally to handle variables (along with its "is_ref" and "refcount" to tell the interpreter if it's a reference or not). He also shows how these relate to the variables you set in your applications as well as a mention of the xdebug_debug_zval function of XDebug to show how it's handled behind the scenes. He also shows how references are handled with accompanying images to show the flow. If you'd like more information on variable handling, Derick points to this article for more detail.

John Mertic has put together a what's new list in the upcoming PHP 5.3 release:

PHP V5.3 is set to be released by the end of 2008, and many of the new features in this release have been in the planning stages for a few years. Originally touted as "PHP V6 without native Unicode support," PHP V5.3 has been developed into a feature-rich upgrade to the PHP V5 line. [...] In this "What's new in PHP V5.3" series, we'll look at these new V5.3 features, and see how they are used and how they can be used in your Web application.

In this first part of the series he talks about:

• Improved static method and member handling
• The _callStatic() magic method
• Dynamic static calls
• Late static binding
• Standard PHP Library
• Circular garbage collection