Right now I'm working on an application which is experiencing lots of interest - and therefore lots of load! We needed to look at ways of trying to bring down the pressure on the servers, and decided to use a CDN (Content Delivery Network) for our image files. It was surprisingly painless to implement once I got into it so here it is in case it's helpful. Continue reading
My worker scripts have really basic logging (as in, they echo when something happens, and I can see those in the supervisord logs). Which is kind of okay, but I wanted to at least add timestamps in to them, and maybe send emails when something REALLY bad happened.
I'm a huge fan of Monolog so I grabbed that, but it wasn't immediately obvious which of the many and varied options I would need for this fairly simple addition. It turns out that the right thing to use is the
ErrorLogHandler, so now my code looks like this:
<?php require "vendor/autoload.php"; $logger = new \Monolog\Logger("log"); $logger->pushHandler(new \Monolog\Handler\ErrorLogHandler()); $logger->addInfo("Something happened");
And the output is neatly in lines like this:
[2014-06-05 17:00:47] log.INFO: Something happened  
You can do a lot of different things with Monolog, but since I had to look up this simplest of all options, I thought I'd share.
A while ago I did some benchmarks on how different versions of PHP perform in comparison to one another. This isn't a performance measure in absolute terms, this was just benchmarking them all on the same laptop while it wasn't doing anything else, and averaging the time it took to run the benchmark script.
Recently I ran it again for versions PHP 5.3 through PHP 5.6 and I thought I'd share my results:
I've got an application that uses Beanstalkd to queue up messages, and some PHP worker scripts that grab messages from the queue and process them. Messages get added by the web application, but can also be added by cron - and when I add a bunch of messages via cron, I don't want to swamp what the web application is doing! Those cron-added jobs are mostly pretty low priority, generating reports, sending weekly update emails, that kind of thing. Beanstalkd has a concept of priority, so I can create lower priority jobs by using code like this:
<?php define("LOW_PRIORITY", 2048); // default is 1024 $queue = new Pheanstalk_Pheanstalk($config['beanstalkd']['host'] . ":" . $config['beanstalkd']['port']); $queue->useTube("scorem")->put(json_encode(array("action" => "my_important_task")), LOW_PRIORITY);
This will add the job to the queue, but anything with a higher priority value (where 1 is the highest priority!) will take precendence. This way I can add as many non-urgent jobs as I want to to the queue without impacting my website performance. My setup has multiple workers and also I tend to write a script that puts loads of tiny jobs on the queue rather than putting one monster task on there. I find this approach a bit more fault-tolerant and also means that incoming tasks can get a chance to get serviced rather than waiting for some crazy huge thing to finish.
I had real issues finding information about the priority settings for beanstalkd and PHP, so hopefully if anyone is looking for it, they will find this post :)
We have a couple of new features coming in to PHP 5.6 with names that sound much less exciting than the features they actually represent: "variadic functions" sound positively academic, and "argument unpacking" isn't exactly catchy. However they both use a new operator in PHP which looks like an elipsis (three dots ...) and is referred to as either the splat operator or the scatter operator. I included them in a recent version of my "Upgrading PHP" talk so I thought I'd share the examples here too in case anyone is interested. Continue reading
Recent additions to the joind.in API have introduced some new dependencies so we decided we'd start using Composer to manage these - but we don't want to run composer unsupervised. I'm sure this will bring the rain of "just run
composer install, it's probably mostly almost safe" criticism, but actually it's quite tricky to run Composer without excluding
vendor/ from source control so I thought I'd share how we did it so that anyone who wants to do so can learn from my experience!
I have just introduced Beanstalkd into my current PHP project; it was super-easy so I thought I'd share some examples and my thoughts on how a job queue fits in with a PHP web application.
I have an API backend and a web frontend on this project (there may be apps later. It's a startup, there could be anything later). Both front and back ends are PHP Slim Framework applications, and there's a sort of JSON-RPC going on in between the two.
The job queue will handle a few things we don't want to do in real time on the application, such as:
- updating counts of things like comments; when a comment is made, a job gets created and we can return to the user. At some point the job will get processed updating the counts of how many comments are on that thing, how many comments the user made, adding to a news feed of activities ... you get the idea. Continue reading
I've had a little flurry of enquiries about training lately, so I thought I'd mention the courses I have coming up, as especially the PHP ones are topics that I don't run public classes on all that often. At the time of writing I have some space on all of these classes: Continue reading
My current project sees Celery (a python distributed task queue) added to my PHP application. There's a handy PHP interface to the RabbitMQ that Celery uses as a backend, which makes it easy for me to create jobs, called celery-php. This requires either the PECL AMQP extension or alternatively it has experimental support for the PHP library for AMQP - I would normally prefer the PECL version but ran into version compatibility problems, missing manual pages, and decided that a pure PHP solution might be more portable and perhaps I would just add the experimental branch to my
composer.json file for this project. Continue reading
My current project does periodic releases, we build a few things, then we work on getting a bunch of user feedback and changing/fixing things before we actually release. This means we need to be organised with tags and branches. We're using GitHub for collaboration, including our issue trackers, commits which contribute to an issue have the issue number in the commit message, and when a branch merges in to the main line, we use the "fixes #42" notation to simultaneously close off the issue that it relates to.
This has been working pretty well, and today I got the question "what's new since I last saw this project?" - so I created a changelog. It's rather rough-and-ready but I had fun so I thought I'd share. Continue reading