What are some rules to follow to allow scalability?

A client often insists that I make sure that any websites I d开发者_开发技巧evelop for him are designed for scalability and faster performance. I'm wondering what that actually means, in practical terms. What do I have to do to fulfill this requirement? I mostly build web apps using PHP/MySQL/AJAX.

Statelessness!

(AKA: share nothing).

Let me explain: In order to allow you application to easily handle more traffic you need to be able to easily throw in more "thingies" (servlets/servers/processors/handles/responders exact terminology determined by the technology you use). For this to work those servlets cannot assume they will always see requests from the same user (when you have many identical servlets, a given request can end up in each one of them). Thus, a servlet cannot "remember" something from a previous request. All data pertaining to the current request should be part of the request itself.

scalability means how your web app would behave as more number of user-requests hit your server. Most of the time basic tests that you run might not tell you the reality that the web app will face. So test for performance of your app in normal and bigger scales. Few things that might help you scale up are: 1. try to minimize points of your code that block. 2. Use memoization (cache proxy) for expensive computations that can be looked up instead of recomputation if possible. 3. use client side cache if necessary. (eg this is possible in flex, actionscript apps) 4. optimize your core functionality for handling bigger input.

scalability might also be related to hardware, db storage's capacity to handle big input.

Build your apps so they are suitable for load balancing across multiple servers and perhaps even multiple sites. I'm not sure what the PHP precautions for that are; for Java based apps, that means strictly following the Enterprise Environment guidelines.

The key is that every request needs to have all the information necessary to service the request, and that resources/responses be cacheable.

http://en.wikipedia.org/wiki/Representational_State_Transfer

Statelessness is huge, as noted by Itay. Plan to scale OUT rather then UP whenever possible. Loose coupling facilitates and buffers the path to scalability as well. Employ parallelism where appropriate, whether parallel execution across servers, or multithreading within a single process or service. Avoid putting too much work on the DB server(s). Consider partitioning/sharding strategies. Use caching wherever possible.

Also note: scalability != availability. There are other concerns to address if availability is an issue.

One more note: instrumentation! Instrument/configurably log/configurably trace EVERYTHING! If you can't get detailed information on the behavior of a piece of your system, scaling becomes more difficult and more expensive. Now, this doesn't mean run your production system with enter/leave trace code running, but it does mean make sure you don't have any gaps, and address them as you find them, otherwise you'll be chasing your tail and fixing the wrong problems.