There seems to be a hell of a lot of confusion about the differences between performance, scalability and high availability. They're often mixed but they're never the same.

So what are the differences?

High availability means that you exceed the required uptime for the application you are running. Generally, it's measured in "9's", as in 99.9% uptime, 99.99% uptime or the overly discussed "five nines" - 99.999% uptime. This is a deep subject, and something we'll discuss another time. So, let's move into the other two.

Right, performance != scalability. Scalability is a formula for growth, performance is you analyze to effectively (based on business requirements, cost, etc) leverage key - and usually heavily used - components of an architecture.

Scalability is fundamentally a question of economics, not development

The way you scale any system is that you build something that has PREDICTABLE level of performance, and then estimate the associated hardware/architecture cost. You only need to pay developers until that predictability level gets to a point where the associated hardware cost is less than the cost of further development. This is a "smart" architecture, and the basis that almost all major social networking sites use (flickr, youtube, myspace - especially), as you should only pay for the scaling you need to do RIGHT NOW, not future needs. MAYBE you consider building for a few months out based on your previous growth or others already playing in the market.

Optimize only what you have to, when you have to

One common mistake people make when building social networking sites is over optimization - a very expensive, complicated and time consuming process that requires the absolute top-notch consulting and engineering talent. Not only do you lose out on the capital you invest, but your opportunity cost is amplified dramatically as your core development assets are focused on non-revenue generating activities masquerading as a benefit to the product.

Shop for performance, implement a scalability plan

Scalability is the thing they should be focusing on, not performance. A high end rack of servers might cost $30,000 or even $60,000, but a team of developers working for two months might cost upwards of $100,000 depending on the size of the project. Not to mention that you can ALWAYS amortize the cost of the servers over their lifetime of deployment, you have leasing benefits (often at 0, 1, 2 or 3% interest), and you can write them off on your taxes as assets to the business. Your development money is gone the moment you distract your developers.

You can't control everything, so get as much control over what you can first

Focus on the things you can tightly control readily first. You can add a server in a matter of days, sometimes it takes months to identify a performance bottleneck, and you don't want to have to deal with it when you application is getting crushed.

Process, not a result

And here's the final point: performance is a process and not a result. You don't achieve performance, you only reach a point where the performance of the site or application is acceptable to the business requirements for right now.

Performance changes massively as features are added and removed. In fact, it's one of the many factors you have to correct for during implementation stages, as performance usually degrades geometrically as complexity increases over time.

In short, you want to waste a load of money? Over-optimize your application.

Ongoing VS on-release optimization

There are basically two types of controls for performance, you can test incrementally or you can test at the end of a release cycle. And then based on testing you optimize. You can also test for performance surrounding problems, to help identify and reproduce the problem - this is very useful in development and commonly done as "common sense, just fix it" for issues found in live applications.

Both have their advantages, and it all depends on the type of project you're implementing. Regardless, you want to be able to scale up infrastructure if performance becomes a factor, because some features are going to be expensive regardless of how well they are optimized for performance. Examples include image rescaling, heavy calculations, complex database queries, data warehousing access, reporting, etc. These types of activities always suck the life out of your application, and they're common. But more to the point, these are the components that you need to optimize for performance - and then adjust your scalability models to suite.

Goals first, then spend time and money

Whenever I hear a developer tell me they're optimizing for performance, the first question I have is "what performance"? As in, "what level of performance do you know you need to achieve - what's acceptable? And how much will it cost me to have you building 'performance components' when you have no idea what level is adequate?" You MUST set a TARGET. Sometimes performance actually means REMOVING features from a product. A great example of that is Pixar. They have a rule that they won't render any technique in house that requires more than a minute per frame to render. And that's a business question based on the scalability of the application. You may not be able to answer that question during your initial development, but it damn well better start getting managed after you launch your application and have an idea of your applications characteristics - generally right after Alpha or Beta. For this to be a selling point on a 1.5-2 year old application platform is retarded.

The RoR lesson: don't purchase performance: purchase a scalability model

Performance isn't a selling feature - if you're not engaging planning when building performance applications you can spend a lot of your time building efficiencies you will never use, and that are overbuilt for your application. No point in putting a Porche engine on your skateboard if all you need is damn skateboard.