I've been thinking a lot about the state of hosting in PHP lately, mostly as a result of working with a few different clients on their setups (including one that bought brand new hosting a month ago and got a PHP 5.3.3 platform), and also being at DrupalCon and meeting a community who is about to make a big change to their minimum requirements. With that in mind, here are my thoughts and tips on choosing hosting. Continue reading
With a week to go, everyone attending PHPNW is starting to get excited. One of my highlights of the weekend is always the hackathon; as an open source project lead it's fantastic to meet new contributors and get a chance to hack in person with them and the more established people from the project.
This year will be no exception: PHPNW's Hackathon is on the Friday evening - you need a conference ticket, and you need to tick the "hackathon ticket" box. Joind.in will be there and we've got a very big todo list so if you are looking for something to hack on, then look no further! Continue reading
There are lots of reasons why you might like to compile your own PHP extensions. For me those reasons are usually:
- The extension isn't available on pecl (e.g. uprofiler)
- The extension is on pecl, but you need the newest version or a branch with a particular feature or fix in it, perhaps for testing
- You are fixing an extension yourself (yay, we need more people like you!)
Related: If you followed my previous post on compiling PHP, be aware that in the
php/bin/ folder there is a pecl binary that will install extensions correctly for whichever version of PHP it belongs to, so you may not need to read the rest of this post. However if you do, the paths follow on from the examples in that post.
I haven't seen a really approachable guide anywhere, we tend to speak of extensions in hushed tones, and actually it isn't particularly tricky so here is my quick how-to guide. Continue reading
When I advise people about upgrading their PHP version, I say things like "just run your test suite with the new version" "just grab the new version and try your site with the built-in webserver". A couple of people recently have asked for more detail on how to actually achieve these things so here's a quick primer on getting new PHP without touching anything to do with your existing PHP installation. Continue reading
I am delighted to announce that I have new video titles available! I'm delighted for two reasons: selfishly, because these things take a lot of prep and I am pleased they are done; but also because I think it is very good news that a key industry player such as O'Reilly recognises PHP's place in the world and works hard to publish new content in this area.
There are two videos available: PHP Web Services and Intermediate PHP (subtitle: a bunch of things Lorna thinks will make developers' lives and applications better!), you can click through (disclaimer: affiliate links!) to get more information and a detailed chapter outline for each course. I hope that either or both of them will be useful to you. Continue reading
We've started using Travis CI on one of my projects to run some build processes to check that everything looks good before we merge/deploy code. One thing I ran into quite quickly was that I wanted to install phing in order to use the build scripts we already have and use elsewhere, but that it isn't provided by default by Travis CI.
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 :)