Make sure to include this in your reading today. Read it slowly, perhaps a few times. It’s interesting stuff to keep in mind if you’re concerned about achieving maximum performance in your PHP applications.

Thanks Gopal Vijayaraghavan, link via Greg Beaver.

AKA: Mashery Recruiting at php|works

The company I had pleasure of co-founding last summer is once again on the prowl for top-notch, Zend Certified PHP developers.

We’re taking the hunt for these folks to php|works in Atlanta. Whenever possible, Mashery will be luring the quality developers with free beer.

That’s right: free beer that is free, as in beer.

We’re also sponsoring a lunch on BOTH Sept 13 and 14, as a good coder knows she cannot code on beer alone.

Show anyone from Mashery some proof that you recently took a PHP 5 Zend Certification Exam or are already PHP 5-Zend Certified, and we’ll enter your name in a drawing for a free 8GB Apple iPod Touch.

Cool, but Why Mashery?

Aside from the beer and a chance at a kick-ass iPod, why would you care about Mashery?

Well …

• Mashery is doing demanding PHP work at the bleeding edge of today’s most exciting technologies, such as mobile applications, AJAX and of course, web services.

• We work with cool tools like Amazon EC2 and S3. And we work them hard.

• Mashery’s clients represent a growing stable of very high volume web services. We tune our services to shave milliseconds off their runtime, and pound on PHP until it (occasionally) weeps.

… among other things.

After more than a year since co-founding Mashery, I can honestly say that in my ten years of working with PHP, I have never had more fun. The work is very hard, but very rewarding. And, it’s always interesting; as a “smart proxy” operator, Mashery’s engineers are constantly facing new challenges and solving them in creative ways.

Never a dull moment, as they say. That’s Mashery.

Up for it?

If you’re interested in learning more about Mashery and our unique opportunities, drop us an email at jobs. The job posting is here.

If you’re going to be attending php|works in Atlanta, be sure to look me up. I’ll be there with fellow co-founder Kirsten Spoljaric from Wednesday thru Friday evening. Email phpworks to set up a time to meet with us, or to find out about what our beer and food distribution schedule will be.

mashery, php 5, phpworks

Facebook experienced a technical glitch over the weekend. The nature of the glitch was that the source code for the Facebook homepage was displayed instead of the result of the execution of that source code. Widespread news of the glitch first broke in this TechCrunch article by TechCrunch writer and OmniDrive founder Nik Cubrilovic.

I agree with Cubrilovic that the inadvertent delivery of source code instead of the result of that source code is certainly a horrific situation, with potentially serious ramifications for any company that experiences such a problem on a large scale basis.

That a company like Facebook, currently a hot ticket for searches, articles and blog posts, would experience this kind of problem is noteworthy.

Unfortunately, the updates appended to the article imply that PHP is somehow responsible for this leakage. In the first article update, Cubrilovic states:

It seems that the cause was apache and mod_php sending back un-interpreted source code as opposed to output, due to either a server misconfiguration or high load (this is a known issue).

On the first of Cubrilovic’s suggested causes, server misconfiguration: well, duh.

Of course servers will behave strangely if they are misconfigured. The world of a system administrator is one of details, and when it comes to managing load balanced web servers for an extremely high-traffic destination like Facebook, it’s a world of a large number of details. Miss one of them and things will predictably start breaking in unpredictable ways.

On Cubrilovic’s second allegation: It’s “a known issue” that PHP barfs out source code under high load? I’ve been writing PHP code for some very, very high traffic websites for over 10 years, and this is the first I’ve heard of this.

Surely we in the PHP community would have heard from someone like Rasmus if PHP were prone to puking source at a high load. As an infrastructure architect at Yahoo!, Rasmus has likely seen how PHP behaves under load levels most of us only fantasize about. If PHP coders were building their applications on a platform pre-destined for Twitter-like failures, no doubt we’d have heard about it by now.

Can anyone provide links to articles or posts indicating that PHP will eject application source under a heavy load?

It’s infinitely more likely that Facebook’s problems were caused by a system administrator breaking some web server configuration (possibly not even PHP-specific configuration), or a new installation of a mod_php build that hadn’t been tested properly in a non-production environment.

Cubrilovic’s second amendment to his article links to an article on his own blog, Learning from Facebook: Preventing PHP Leakage.

Given the likelihood of this issue’s cause being server misconfiguration, it is disturbing that Cubrilovic’s first tip for avoiding this kind of problem is to install and correctly configure the powerful and complex Apache module mod_security. After all, if the a sysadmin can’t get Apache and PHP configured properly, how likely is it that they’ll be able to get two modules configured properly?

The rest of Cubrilovic’s tips also relate largely to web server configuration, such as making certain files inaccessible from direct requests.

The disappointing part of the FUD that Cubriolovic is spreading is that anything more than decent release practices are necessary to address and avoid the problem Facebook experienced.

I can only imagine why Cubrilovic has invested this weekend in undermining people’s faith in PHP’s reliability under heavy load. What I can tell you, though, is this:

PHP doesn’t cause website problems and inadvertent code leaks. People making mistakes while using PHP and other powerful tools do.

However, that fact isn’t worthy of two articles, so perhaps that’s why Cubrilovic went with the PHP-as-boogeyman-that-must-be-defended-against approach instead.

What’s the take-away from all this? Servers are powerful, and can be complicated. Tread carefully. Don’t roll untested configurations of web servers and related modules out on production without testing them in an identical staging environment.

Know what you’re doing, and do it carefully.

facebook, php, techcrunch