News Feed

News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way Blog:
Fault tolerant programming in PHP
July 17, 2014 @ 10:44:04

The blog has a new post today looking at fault tolerant programming in PHP applications. Essentially, this means writing your code so that error conditions are handled gracefully and with as little impact as possible.

In your application, every time you call an "external" service you are vulnerable to the failure in that service. That either might be a third party API being down, your database being unresponsive or unexpected errors from the 3rd party library you are using. With many developers and companies being interested in composing applications out of microservices at the moment, guarding for failures because of broken dependencies gets even more important.

They describe a situation where data is coming from an external source (an inventory service) and a timeout or connection failure occurs. They propose a sort of "circuit breaker" to be put in place to protect the application, fail fast on error and maybe even retry until the request is successful. They also point out a library from oDesk, Phystrix, that allows for fault tolerant execution through a wrapper that traps errors and deals with them instead of just breaking. This is the first part of a series, so in part two they'll show the library in use along with the React HTTP client.

0 comments voice your opinion now!
fault tolerant application phystrix library execution failure


Lorna Mitchell:
PHP 5.6 Benchmarks
May 19, 2014 @ 09:32:18

Lorna Mitchell has put together a set of benchmarks for PHP 5.6 comparing them to the three previous minor versions, PHP 5.5, 5.4 and 5.3 based around the same setup as her previous benchmarks of PHP 5.4.

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.

There's a steady drop in execution time over the series of versions, with PHP 5.6 coming in the shortest. She also includes the actual numbers of the results in case you'd like to chart them out yourself.

0 comments voice your opinion now!
php56 benchmark previous version execution time


Chris Jones:
Tracing Silex from PHP to the OS with DTrace
November 06, 2013 @ 12:31:23

Continuing on with his look at using DTrace in with PHP, Chris Jones has a new post in the series showing how to add traces to Silex-based applications, including sample output.

In this blog post I show the full stack tracing of Brendan Gregg's php_syscolors.d script in the DTrace Toolkit. The Toolkit contains a dozen very useful PHP DTrace scripts and many more scripts for other languages and the OS. For this example, I'll trace the PHP micro framework Silex, which was the topic of the second of two talks by Dustin Whittle at a recent SF PHP Meetup. His slides are at Silex: From Micro to Full Stack.

He includes a brief guide to getting the DTrace support up and running based on instructions in a previous post based on some pre-build Oracle linux packages. He links to the latest DTrace Toolkit and the downloads page to get the latest version of Silex. He sets up a super-basic Silex application (one route, "hello") and shows how to run the DTrace against it. His sample output shows both the PHP files being called and the functions/methods called inside them resulting in an output over a thousand lines long.

0 comments voice your opinion now!
silex dtrace trace execution oracle package toolkit tutorial

Composer still susceptible to remote code execution via MITM
October 03, 2013 @ 11:26:15

In this recent post to, a point is brought up about the popular PHP package manager, Composer about it being susceptible to a common attack called the "Man in the Middle". This issue on the project's Github repository talks more about it:

Composer runs code from HTTP sources without validating the source of the download or the code downloaded. As such, trivial man-in-the-middle attacks through any number of vectors (dns, networking, local server exploit, etc) will result in execution of code of an attackers choosing at the userlevel of the user running composer. (Typically a developer account)

Replace for a given network perspective by replacing it with a malicious http instance (eg by changing the DNS locally, at the lan, at an isp or hosting provider dns resolver, or globally or equally easily by replacing a route to the legitimate server (eg arpspoof)) . The http server instance is configured to serve a malicious /composer.phar and a /version url that produces random data. When users run self-update, the malicious code will be downloaded and run as the user that is executing the self-update command.

As of yet some patches and ideas have been proposed to correct this issue, but it hasn't been resolved and is currently listed as a "blocker" on the project. One suggestion, signing packages, seems to be the front-runner in the current discussion, something that package managers for other languages have already implemented (like npm for Node.js and pip for Python).

0 comments voice your opinion now!
composer package manager remote code execution attack maninthemiddle mitm


SitePoint PHP Blog:
Running Tasks in the Cloud with IronWorker
September 13, 2013 @ 10:37:09

On the SitePoint PHP blog today there's a new tutorial showing you how to run tasks "in the cloud" using PHP and the Iron Worker service.

In this article I'm going to show you how we can use IronWorker to run code in the Cloud, just as if it were being run inside our PHP application's code. There are a number of advantages to running tasks in the cloud, for example: processor-intensive tasks can be offloaded from your web server, better fault tolerance and the execution of your code isn't blocked waiting for long-running tasks

The tutorial uses a Ruby-based CLI tool and this PHP Package to setup and execute the tasks. They walk you through the creation of a first task script and help you create the ".worker" file it needs to execute. With the IronWorker PHP package, you can quickly create these workers and configure things like schedule, data to send or - as their last example shows - send emails directly from the worker.

0 comments voice your opinion now!
ironworker cloud task execution ironio

Facebook invents a PHP virtual machine
August 08, 2013 @ 10:20:54

On there's a new article posted about an update Facebook has made to their HipHop virtual machine (HHVM) version that is supposed to execute PHP nine times faster than its normal rate.

Social networking giant Facebook has taken another step at making the PHP Web programming language run more quickly. The company has developed a PHP Virtual Machine that it says can execute the language as much as nine times as quickly as running PHP natively on large systems.

An engineering manager for Facebook pointed out the goal of the update - "to make PHp run really, really quickly." The HHVM compiles down the PHP code into C and executes it directly, removing the need for the PHP interpreter.

HHVM is the next step for Facebook. Under development for about three years, HHVM actually works on the same principle as the JVM (Java Virtual Machine). HHVM has a JIT (just-in-time) compiler that converts the human readable source code into machine-readable byte code when it is needed. (The previous HipHop, renamed HPHPc, has now been retired within Facebook.)

You can find out more about the HipHop virtual machine over on Facebook.

0 comments voice your opinion now!
facebook virtual machine hiphop vm execution compile


Pádraic Brady:
Getting Ahead In Security By Watching The Neighbours
January 18, 2013 @ 11:53:52

In his latest post Padraic Brady talks some about the recent security issues that happened with Ruby on Rails that allowed for remote code execution and how, if you use code blindly, you could be in for a similar fate.

Code execution vulnerabilities are, by definition, hideous monsters. The ability for external inputs to enter an execution context (i.e. injecting or manipulating code that is executed on the server) can be difficult to spot through the haze of convenience that such machinations are often designed to deliver. In Rail's case, that convenience was to automatically cast data entries in XML or YAML inputs into Ruby types including, unfortunately, Symbols and Objects.

These types of "buried" code execution vulnerabilities are still easy to locate in PHP, at least, because you are still restricted to normal code execution pathways in the absence of Ruby's dark magic, e.g. eval(), include(), require_once(), system() and, let's not forget, unserialize().

He talks about how, if you're not careful with the code (third party libraries) that you use in your applications - or don't adhere to good security practices in your own - you could be vulnerable to a similar style of attack. After some investigation on his part, he discovered an issue related to this in the Symfony2 YAML parser (now fixed with a new release).

To summarise… Pay attention to competing applications or frameworks - their problems may also be your problems. If you're worried about arbitrary code execution vulnerabilities then audit your code. You can even, as a sanity check, use grep to find uses of functions like eval(), unserialize(), etc and analyse where their parameters' might originate from.
0 comments voice your opinion now!
rubyonrails security vulnerability code execution yaml symfony2

Lorna Mitchell:
PHP 5.4 Benchmarks
July 19, 2012 @ 09:54:42

In this quick post to her site, Lorna Mitchell shares some of the benchmark results she found when doing some tests with the latest version of PHP - 5.4.

Today I'm giving my first ever talk at OSCON - about PHP 5.4 (I'll also be giving my second ever talk at OSCON, about RESTful services; it's a busy day!). My talk includes some benchmarks which I thought I'd also share here. [...] This graph shows the performance of four versions of PHP (because the bench.php script that lives in the php source tree didn't appear until 5.1). The axis up the left is the time it took to run the benchmark script - so a smaller number is better news.

You can see a dramatic difference between even just the latest in the PHP 5.3.x series in the 5.4 results. There's also a table with the details of each of her 10 executions of the "bench.php" script showing the results of the time spent to run the script on four different PHP versions.

0 comments voice your opinion now!
benchmark version execution time performance

Dave Marshall's Blog:
How I'm doing TDD with PHP
June 07, 2012 @ 11:31:51

Dave Marshall has shared his method behind using test-driven development in his recent development.

I've been watching the Destroy All Software back catalog over the last couple of months and it's really inspired me to up my TDD game. I'm still fairly new to TDD, I've written tests for a long time, but never really let it lead my development…

He talks about the testing tool he uses and some of the ideals he keeps in mind when developing his tests. He also comments on testing isolation, speed of execution, the "fail fast" idea as well as integration testing and continuous integration.

0 comments voice your opinion now!
tdd testdrivendevelopment tool execution

Gonzalo Ayuso's Blog:
Checking the performance of PHP exceptions
January 17, 2012 @ 08:02:24

Gonzalo Ayuso has a new post to his blog today looking at the performance of PHP exceptions and how it could effect your application's overall speed.

Sometimes we use exceptions to manage the flow of our scripts. I imagine that the use of exceptions must have a performance lack. Because of that I will perform a small benchmark to test the performance of one simple script throwing exceptions and without them.

His (little) benchmarking scripts are included - both looping 100000 times, one throwing an exception and the other not. The results were pretty obvious - the memory usage was about the same but the speed was about ten times faster without the exceptions (in PHP 5.3). In PHP 5.4, however, the numbers were closer as far as time to run. Obviously, unless you make super heavy use of exceptions, you're not even going to come close to something like this (micro-optimization anyone?).

0 comments voice your opinion now!
exception performance benchmark execution time memory

Community Events

Don't see your event here?
Let us know!

library introduction symfony podcast composer security artisanfiles interview series language version list release laravel framework conference community tool voicesoftheelephpant opinion

All content copyright, 2014 :: - Powered by the Solar PHP Framework