Category: PHP

I have always wanted to play with Symfony since I heard many cool things about the framework. Finally got some time and started studying the framework. I would save the experience for another blog post. However I am going to share how easy it is to load external libraries.

Libraries supporting PSR-0 standard
If the library was written according to the PSR-0 standard, it is already well structured with the proper implimentation of namespace. For such libraries, just open up “app/autoload.php” and add the namespace to the array which is passed to the $loader->registerNamespaces() method. Your codes should look something similar to:

Libraries supporting PEAR Conventions
Libraries with support for PEAR conventions could be easily loaded as well. Just pass the autoloader prefix (the first part of the class name or the root directory name followed by underscore) to the $loader->registerPrefixes() method.

Something like:

In such scenarios the class MyLib_MyClass should reside inside __DIR__.’/../vendor/mylib/src/MyLib/MyClass.php – as the PEAR standard suggests.

The Old and Incompatible ones
PHP has a very long history of evolution and there are plenty of community maintained codes which haven’t yet been updated to reflect the modern development standards. There are many 3rd party libraries out there which are old (was written before PHP 5.3) but useful. While there is no direct way to load them into Symfony, thanks to the nifty autoloader, we can easily use them with Symfony2.

Say, we have a class like this:

It is a single file library – no namespace, no PEAR naming. What do we do? We make it PEAR compatible 🙂

# First rename the file according to the class name – KillingCurse.php

# Now create a vendor and source directory under the “vendor” directory of the app. Say, we name “voldemort” as the vendor and name the source directory “src”. The file structure would be- “/vendor/voldemort/src”. This is not a requirement, we could just create any directory under the “/vendor” directory but follwing the Symfony naming convention is a good practice.

# We need to create a prefix, so we create a directory named “Spells” (/vendor/voldemort/src/Spells)

# We put the KillingCurse.php under the Spells directory and define a Spells_KillingCurse class in the same file like this:

The full file now looks like:

# Now we register the “Spells_” prefix to the “app/autoload.php”:

# We use the following codes in the controller:

Points to be Noted:

— \Spells_KillingCurse::load(); We are using a static call which does nothing. But this makes the autoloader load the file in which the bare KillingCurse lives. We used a static call instead of having to initiate an object.

— An extra class without any functionality is added just so that entire file is loaded. Any functions, classes or constants will get imported into the global namespace.

— Be sure to use the “\” before the classes, functions etc. You’re inside a namespace and you must refer to the global namespace to use items in the global scope.

— There could be many other ways to do this. Like I mentioned at the top of this post, I am just beginning Symfony2. I would love to hear new ideas or suggestions to improve the codes.

On a Leevio project, I’ve been entrusted with the responsibility to build an engine that processes huge data with heavy network IO. The engine needs to integrate seamlessly with the web front end. Since we had many of the business logic already done in PHP, I preferred to go with PHP. It’s not like that we didn’t have an option. I could go for Python, but then I would have had to port my existing ZF models to Python or build some APIs to access data through another layer of abstraction. I wanted to keep it simple and short. And I had a feeling, if the pros (Yahoo!, Digg, MailChimp, GrooveShark, Xing and who not?) can do it with PHP, why can’t we?

I built the core engine on Gearman. It was simple, stupid and very easy to get things done. My workers were running fine in the test phase. But it didn’t turn out that easy when the workers grew complex. PHP was not built for long running requests. It’s internal caches and circular object references were draining memory like hell. With the different performance optimizations I have made, it has improved over the period of time but still it can sometimes leak memory like anything. Besides, the awesome garbage management was introduced only in PHP 5.3 and we didn’t dare upgrade (because some of the legacy technologies used in the project). The engine was working just fine but I was having a hard time keeping it alive. Sometimes the processes exhausted into Zombie Process.

I’ve tried register_shutdown_function to quit and and restart at the completion of every job processing. It worked well but was still not enough – the zombie processes were not being restarted. 🙁 I didn’t want to impose memory limit either – that might have terminated the process in the middle of a job (and the hell will break lose!) 🙁

I then started googling for any mechanism to manage PHP workers with Gearman. I found “Supervisor”. Grooveshark and many others use it with PHP and Gearman. It’s a very simple tool to handle your workers (not just Gearman workers, literally any command). It actually starts the processes as it’s subprocess and can identify the death of processes running under it. The most important part is – it can auto restart the processes based on custom configurations (depending on exit codes). The configuration is simple. You define a command, configure it and then run supervisor. With supervisor, I’m running the PHP processes in a similar fashion to the web page handling. Every time the work is complete, the process quits and supervisor restarts it. The process goes in an infinite loop, waits for new workload. When the workload arrives, it works and then again quits – this repeats.

The engine is now more stable and working fine. So, if you have to manage long running workers with PHP and Gearman, do consider Supervisor to manage your workers. It shall pay off!

Here’s a quick How To on getting started with Supervisor:

Installation
Supervisor is a Python daemon and available from pypi. So you can “easy_install” it. First, we install Python setuptools (to enable easy_install):

Now we install supervisor:

The I created “/etc/supervisord.conf” with the sample config by typing:

Then I removed the unnecessary parts and kept what I need. Check out the Configuration Manual for better understanding and full coverage on the available options.

After saving the configuration, run Supervisor in debug mode to check if the configuration is okay. Debug mode doesn’t send supervisord background and prints errors on the console. Use it like this:

When debugging is done, simply run:

It’ll run supervisor, spawn the sub processes, detach from terminal and get into daemon mode.

What’s Next?

Well, this does my job perfectly. But if you want to do some more tricks or advanced stuff, you should look at the Process Controll Extensions of PHP to take the advantages of native Unix environment!

Happy supervising!