Good news everyone! ©

I'm proud to announce Pinba - a statistics server for PHP.

What is it?

It's a daemon gathering information sent by PHP processes by UDP. In the same time Pinba acts as a read-only storage engine for MySQL, so you can use good ol' SQL to access the data.

What is it useful for?

We at Badoo.com have a lot of web-servers running PHP and want to know where are the most problematic places in our PHP code and which services are loaded the most. There is no need to store that information for further analysis, therefore Pinba doesn't actually store the data - it keeps it only for 15 minutes (you can change that, of course), which is more than enough to update graphs (we use RRDTool for that part) and to check things like "what's the slowest operation in script.php at server #5" or "which memcache server is the slowest" and alike. Complex queries can be also handled using raw data tables, which provide direct access to each request data, but in most cases reports do the job.

More details you can find on the website: pinba.org

I'd love to get some feedback, so don't hesitate to join Pinba development mailing list.

We needed to locate where most of the memory is allocated in our scripts (as some of them became too memory hungry), so I've created memtrack extension.
This extension helps us to see unusually big memory allocations in production code.

Of course we use error logging, so memtrack just produces warnings like this one:
Warning: [memtrack] [pid 26177] user function foo() executed in /tmp/1.php on line 7 allocated 4194304 bytes

[memtrack] is a prefix for all warnings produced by the extension, so that one could find them in the logs.
[pid 26177] is, well, a PID, so that one could follow a certain process (if needed).
user function means it's a user defined function; the ones provided by PHP or one of its extension are reported as internal functions.

Memtrack supports the following INI options at the moment:

• memtrack.enabled - Boolean flag, which enables or disabled the extension. Default value is 0, i.e. disabled.
  
• memtrack.soft_limit - "Soft" memory limit. It means that a certain function cannot increase memory usage by more than X bytes and a warning is produced when the limit is exceeded, if the function is not ignored. Default value is 0.
  
• memtrack.hard_limit - "Hard" memory limit. A warning is produced when the limit is exceeded, whether or not the function is listed in memtrack.ignore_functions. Default value is 0.
  
• memtrack.ignore_functions - A comma- or whitespace-separated list of functions, which are to be ignored. The values are case-insensitive, for class methods use Class::method syntax. Empty by default.
  
• memtrack.vm_limit - Virtual memory size limit (set on a process), measured on shutdown only, might be helpful if you suspect a process is "leaking" memory. A warning is produced when the limit is reached. This option is currently available only on Linux (if you know how to get virtual memory size of the current process on any other system - please let me know). Default value is 0.
  

The extension checks memory usage changes per op_array, which in most cases means a function call or an included file with flat code, so you should not notice any performance loss.

memtrack is still BETA, so let me know if you find any problems there, or if you have any suggestions on how to improve it.
Pierre is working on Win32 build just as I write this, so Win32 dlls should be available soon, stay tuned.

Sorry for such a long downtime, folks. I've had problems with my server and had to do clean re-install of the system.
Bringing everything up has taken quite some time, especially because it all has happened in a very unusual moment - I have become a daddy!
Little Lisa was born December 25 at 11:45 pm and she's taking most of my time at the moment =)

As some of you might have noticed, I've been a bit busy lately creating new PECL extension - sphinx.
The extension provides an interface to a feature-rich fulltext search engine Sphinx written by Andrew Aksyonoff.
We (Andrew and me) made our best to keep the extension as compatible to the pure-PHP API (shipped with Sphinx) as possible in order to make the transition easier, so if you're already using PHP API, you only need to remove (or comment out) the include "sphinxapi.php"; line and enable the extension in your php.ini.
Yes, it's that easy.

I also added a documentation for it to the PHP manual - http://php.net/sphinx, it covers all the functions, but lacks code examples at the moment (contact me if you want to contribute some, it's very much appreciated).

To install the extension you need libsphinxclient (it's shipped with Sphinx since v0.9.8), here is a short installation guide:

# tar -xzvf sphinx-0.9.8.tar.gz
# cd sphinx-0.9.8/api/libsphinxclient/
# ./buildconf.sh
# ./configure && make install

After that PECL will do all the work for you:

# pecl install sphinx-beta

I've got no complaints so far, so I suppose I can call it stable in a month or so.
Until then I'll continue to gather feedback (please use PECL bug-tracker if you encounter any problems, thanks!).

According to GCOV reports, PHP test coverage has recently exceeded 55%, which is really good number, but still not enough. It took us about 2 years to get the last 5% and I believe most of the kudos should go to IBM people, who continue to contribute lots of new tests.
I hope that the Testfest will help us to speed up this process.

Just so that you know what I think about that CLA thing:


Make It Open Or Go Away

PDOv1 was initially a small project created and maintained mostly by 1-2 persons.
Even though it was quite small, it turned out to be a kind of monster which nobody really likes or understands.
Oh.. and did I mention that it never actually worked?

And now we're being forced to have PDOv2, which is of course very much different from PDOv1: it's being developed by a secret group of people (which includes some mysterious "vendors") aand.. it requires signing a legal paper it you want to participate or even read its spec.

PDO does not need a CLA, PDO needs *CARE*.

Doesn't matter how much "vendors" participate in PDO, it's going to be a total failure as long as nobody cares about it.
That was the biggest flaw of PDOv1 and CLA won't magically fix it.