Thursday, February 4, 2010

Need for Speed

Speed. We all crave it, whether it's for a faster laptop, or new phone, or latest operating system, the need for speed is an ongoing quest for us techies. So with the recent announcements from Facebook and even from us at Zend about our latest performance Benchmark, it highlights no single magic bullet or formula. Sure we can all put nitro into our cars and go really really fast for a few seconds, but in the end we will burn out our engines or have some other mechanical failure in the system. As PHP developers, we also know that speed isnt as simple as pouring nitro in a car, our systems are a lot more complex, and change a lot more often, and break a lot too. Speed is not limited by how quickly our Zend engine performs either, but also by how our database, images, browser side code, memory utilization and architecture to name just a few of the common culprits. If you read our Drupal performance benchmarking paper, you would find that in the end we were able to improve performance by over 2605% with a turbo charged version of Drupal, we even got 783% faster on the unaltered codebase, not bad for a few days work right. Well the one thing you did not read about in the whitepaper was how the bottlenecks were discovered and turbocharging accomplished. This is one of those things we rarely measure in benchmark reports or even talk about. In the industry its also known as Time to Repair, or TTR. How quickly can you identify and fix a performance problem (or for that mater, any code problem I would say is just as important in the race for application Speed and reliability)?

Sure the company cares about it. Many firms have Service Level Agreements back to there customers, but how much of our development resources and effort do you really spend trying to improve the team troubleshooting capabilities .vs. website speed?? I'd say the industry average is very very low here, and the performance diagnostics capabilities are crude at best in most PHP firms. So for the sake of time, resources and yes we throw money, and lots of it at our hardware vendor. It seems easier to upgrade our boxes then to dig into the code to try to figure out where the problems are, but what if it wasnt? What if it was easy to see it, what if we had a dashboard that points right to the problem and even told you how bad a problem it was, and what if it told you how often this performance problem occurs during peak times of business. And what if it could help you not only find bottlenecks to speedup your website, but also help with other customer issues. Would it make your company look like a rockstar because you can find and fix problems really really quickly. More speedier then your competitors do?? More cheaply then your competitors can?? This means you have better margins in your PHP business and happier customers at the same time. If you like the potential of improving speed as far as TTR, then take a look at the following diagnostics webinars, it will showcase some of the same technology our Zend experts use here. So start invest in your performance tuning and troubleshooting chops and get great customer satisfaction speed (and loyalty) for your business.


eddiek said...

REPOSTING a good article I read recently about the Facebook announcement, hope that OK as it relates to your article also.

HipHop for PHP is not for you 60% of the time, everytime.


My apologies to Ron Burgundy for the title of the post, but I’m just a fan of the wisest man to ever live.

As Marco and Illia and countless others have said, unless you don’t work with PHP or were in a coma, Facebook released
HipHop for PHP , it’s open source, it’s awesome, it makes you go fast.
It’s not for you.

You, being the average PHP developer, systems administrator, hacker. A lot is being made of how CPU load went down by 50% etc, that’s a great number and on the surface very hard to argue with, but to really understand it, you must understand the problem a lot better. Facebook didn’t decide to write HipHop and use it in production because they had all this money laying around and felt like paying 3 engineers to work on something. They looked at other existing alternatives, implemented them, and when they maxed them out, decided to switch.

HipHop Does Not:

Make your database queries faster. A slow database is slow whether accessed via PHP or C++, Java, Scala, Ruby…..
Make your images load faster
Debug faster / better, if anything you’ll be debugging HipHop and PHP , to make sure something didn’t break in the conversion.
I really want people to understand, that the decision to switch to HipHop isn’t a light decision, and it’s definitely not the silver bullet.
If anything, HipHop should be your last resort.

But, it’ll help me reduce the number of web heads!

It’ll also make you change your deployment process, you’ll have to learn how to use gdb and other tools to debug things in production.
Keep that in mind when you think about the monthly cost of a cloud server, or a slice at slicehost. The number of servers arguments comes into play when you can eliminate > 100 servers.
If you’re going from 4 servers to 2, I guarantee you that you’re doing it wrong.
I suggest you to look into your application more, and find the bottlenecks. Be absolutely certain that you can’t tweak your DB any more, or use APC, or Zend Server or something else.

Clint Byrum said...

Its often a goal in design to make an application "scale horizontally", but it can be equally important that it scale vertically.

Today, with 8 and 16 core boxes readily available, 64-bit OS's the norm, and RAM prices incredibly low, the choice between dedicating two weeks of engineer time with no guaranteed result, or buying $10,000 worth of RAM is easy.

However, with good engineers, and a reasonable peer review process, one hopes that applications will also be designed to be accessible, maintainable, and hopefully, that two weeks shrinks to two days, or even two hours.