Scaling Up vs. Scaling Out: Hidden Costs. In My Scaling Hero, I described the amazing scaling story of plentyoffish.com.
It's impressive by any measure, but also particularly relevant to us because we're on the Microsoft stack, too. I was intrigued when Markus posted this recent update: Last monday we upgraded our core database server after a power outage knocked the site offline. I haven't touched this machine since 2005 so it was a major undertaking to do it last minute. We upgraded from a machine with 64 GB of ram and 8 CPUs to a HP ProLiant DL785 with 512 GB of ram and 32 CPUs ... The HP ProLiant DL785 G5 starts at $16,999 -- and that's barebones, with nothing inside. 7U size (a typical server is 2U, and mainstream servers are often 1U) 8 CPU sockets 64 memory sockets 16 drive bays 11 expansion slots 6 power supplies It's unclear if they bought it pre-configured, or added the disks, CPUs, and memory themselves. At any rate, let's assume $100,000 is a reasonable ballpark for the monster server Markus purchased.
Scalability Best Practices: Lessons from eBay. At eBay, one of the primary architectural forces we contend with every day is scalability.
It colors and drives every architectural and design decision we make. With hundreds of millions of users worldwide, over two billion page views a day, and petabytes of data in our systems, this is not a choice - it is a necessity. In a scalable architecture, resource usage should increase linearly (or better) with load, where load may be measured in user traffic, data volume, etc.
Where performance is about the resource usage associated with a single unit of work, scalability is about how resource usage changes as units of work grow in number or size. Said another way, scalability is the shape of the price-performance curve, as opposed to its value at one point in that curve. There are many facets to scalability - transactional, operational, development effort.
Best Practice #1: Partition by Function At the code level, we all do this all the time. Randy Shoup on eBay's Architectural Principles. Scale ASP.NET Apps Through Distributed Caching. In-Depth Scale ASP.NET Apps Through Distributed Caching High-transaction environments can use distributed caching to boost performance without major code changes.
ASP.NET has become a highly popular technology for developing Web applications. A large number of these ASP.NET applications need to scale to accommodate the growing number of transactions and traffic they support. During the client/server era, scalability wasn't really a concern because there weren't that many concurrent users. ASP.NET architecture allows applications to scale by adding more Web servers in a load-balanced Web farm.