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.
Posts
