Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

What Best Practices should be undertaken for a Website that needs to "scale out" to handle capacity? This is especially relevant now that people are considering the cloud, but may be missing out on the fundamentals.

I'm interested in hearing about anything you consider a best practice from development-level tasks, to infrastructure, to management.

Use your best judgement when posting multiple answers, since it may make sense to post them separately for voting purposes. (hint: you'll likely get more reputation points for many small answers than one large answer)

share|improve this question
1  
Nice question. Should be some good tips here. –  Paddyslacker Sep 8 '10 at 4:36
1  
Look at: highscalability.com –  Casebash Sep 8 '10 at 6:43
    
Can someone who knows about Windows Server App Fabric and caching post something here? I'm not an expert in this area and want to learn more. –  makerofthings7 Oct 20 '10 at 13:41
    
What do you want to know about AppFabric? –  Henrik Feb 11 '11 at 1:59
    
There is some tips on how to Scale a Website, check it out Including: front-end level server script level Model and DB design level Server horizontal scaling, Sharding See more: olivetit.blogspot.com/2013/05/… –  user91773 May 22 '13 at 15:23
add comment

5 Answers

up vote 13 down vote accepted

Design for Concurrency

That is, as you're coding, plan around having multiple threads going. Plan the shared state (often just the db). Plan for multiple processes. Plan for physical distribution.

This allows you to distribute your system across multiple machines, and across multiple processes with load balancing. It allows you to have redundant processes running in case of failure, and in case you need to modify the system in-place, you don't have to kill all service to do so.

share|improve this answer
add comment

A few things you might consider:

  • Separating read- and write-sides of your data storage.
    • CQRS/Event Sourcing
    • CQS
    • Message-passing/Actors
  • Avoiding shared process and thread state
    • Hence avoiding locking
    • You can avoid this through the type system by creating your classes, structs and other data types to be immutable, i.e. non-changing after construction. Especially for complex abstract data types, it works surprisingly well (e.g. jQuery's implementation)
  • Not blocking web server threads on IO. If you are using ASP.Net use asynchronous pages/actions with the APM pattern/task-parallel library (TPL)
  • Not saving loads of state in the user-session dictionary
    • This has to be moved across threads when thread migrations occur in IIS.
    • Having intelligent routing, such that non-secured/static resources aren't served with the same application framework (e.g. ASP.Net) that add overhead. Look at having different web servers, for example.
  • Writing continuation-passing code with an asynchronous workflow-pattern (e.g. bind (haskell)/callcc/Tasks.ContinueWith/F#'s async)
  • Use queueing theory to calculate where your bottlenecks may happen
  • Use push- rather than pull-based updates to read-models and other application state. E.g. through RabbitMQ/nServiceBus
  • Use the least-features applicable 'http handler'
  • For static files, serve e-tags and cache expiry policies to enable the web infrastructure to work as it should (e.g. with squid proxy)
  • (Hire me to solve your scaling issues and get on-site tutorials ;))
share|improve this answer
add comment

Share Nothing architecture.

With that in mind, and contrary to what you might think, don't jump to a scale-out solution right away. The off-system overhead vs. an in-system call should not be under-weighed. For instance, it takes a LOT longer to make an DB connection across any network interface than it does to make a local call. Budget how much time in management, power, and tuning effort is needed in scale-out vs. the extra $ for a true large system.

Regardless, I there is still great value in "share nothing" architectures and you can layer and scale-out your systems when the time comes.

share|improve this answer
add comment

Parallelize requests over several hostnames

Part of the HTTP standard is a section that says webclients will request a maximum of 2 sessions per DNS Host. Here is a solution where you and alias out your www.domain.com and get a higher request concurrency, making your page load faster:

http://stackoverflow.com/questions/3653609/how-do-i-code-my-asp-net-page-to-parallelize-downloads-across-hostnames

Basically it involves editing your ASP.NET HTTP Handler to alternate the target hosts you send clients to, where each host is a CNAME to "www".

share|improve this answer
1  
This answer has more to do with client side performance and nothing to do with scaling out on the server side. –  Ken Liu Sep 18 '11 at 20:19
    
I was thinking more along the lines of a middle tier aggregating other data sources via HTTP. Azure Table, OData are just some examples... To your point, still, it's the server that tells the browser (javascript) what to do. –  makerofthings7 Sep 18 '11 at 20:25
add comment

Secure, Fast, Reliable DNS

I found a few high-capacity websites using the registrar's DNS server, which had no SLA for uptime or performance. In addition, their servers were located in India and the latency alone increases the chance that a DNS spoofer could poison your customer's, or intermediate ISP's cache. This would cause even your SSL-protected traffic to be redirected without anyone knowing.

DNS speed also affects the initial load time of your server, before the records are cached.

I use DynDNS or Neustar to most of my customers since they have a pretty solid DNS infrastructure (though it's expensive and I have no other affiliation to those companies).

share|improve this answer
2  
Err... is DNS really a serious bottleneck for you? I would think that'd be one of the last things to optimize. –  Fishtoaster Sep 8 '10 at 3:22
    
@Fishtoaster - Just edited part in bold. I'm originally a Sysadmin, and DNS security plays a big role in SSL validation. DNS connectivity and performance issues do arise such as: BGP routing issues to the SOA, issues with Anycasting (for CDN's), latency issues, cache poisoning, and more. I wrote a DNS best practice scanning tool (wire level) which I'll put on the internet soon. Feel free to try it out since it covers many of the connectivity issues I mentioned. (or shoot me an email and I'll explain more) –  makerofthings7 Sep 8 '10 at 3:32
2  
I'm not saying that there aren't DNS-related performance issues like the ones you list. It just seems to me that much more basic concerns (database access, page caching, simple code looping complexity, server process load-balancing, hardware distribution point selection, etc) would arise and be solved at several orders of magnitude while scaling up before DNS-related issues would be a problem. –  Fishtoaster Sep 8 '10 at 4:22
    
... I totally agree that there are more important things to worry about, just as you mention. Maybe that's why this idea has a rating of zero :).. but then again, I am the only one who answered this question so far. –  makerofthings7 Sep 8 '10 at 4:25
1  
DNS performance can certainly be a massive bottleneck -- there might not be many ms difference between good and bad, but because DNS gets hit on every call (or nearly every call) it can add up real quick. Especially when you get into modern CDN stunts. –  Wyatt Barnett May 22 '13 at 16:26
show 3 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.