viernes, 15 de octubre de 2010

20090302163516_whypeopleseemtohavefreetime.jpg (700×579)


20090302163516_whypeopleseemtohavefreetime.jpg (700×579)

jueves, 14 de octubre de 2010

How websites handle multiple users simultaneously? « My Blog – My Thoughts

How websites handle multiple users simultaneously? « My Blog – My Thoughts

This time I am sharing my discussions about how all these high traffic sites handle multiple users simultaneously. The discussion is not specific to a certain web site but rather was related to a set of guidelines that every developer should follow to make such tasks easy. There are many things to consider. I would list down some as follows:

  1. Separating the code into distinct independent layers. A classic three tier architecture having a Presentation Layer, Business Logic Layer and Data Access Layer. These layers should be independent of each other and communication paths clearly defined i.e., A layer can talk to the layer below it – no skip or jumps allowed. The reason being independent layers are easy to scale out when the load increases.
  2. In the Presentation Layer use the Session Object appropriately. In fact the default behavior should be to not use the Session object unless there is absolute need for doing so. The main reason being Session Replication being a very costly operation. Although there are many solutions available but still use the Session object as less as possible.
  3. Make the Business Layer or Service Layer stateless. Stateless means there shouldn’t be any instance variables which saves the state of the Service and the respective calls depends upon that state. Again the reason being we can easily scale out these services to other machines and being stateless we can make a call to any one of them. I will talk about the advantages of this in concurrency later.
  4. Make the methods idempotent – multiple application of same operation on same set of parameters return the same result. Again this allows us to retry in case of communication failure or any other circumstances.
  5. Having Stateless Services (no sharing of data between them) also make them highly scalable. They can service multiple threads simultaneously.
  6. Don’t do any premature optimizations in the code. Write clear and readable code. As always said “Premature Optimizations is the Root of ALL Evil”.
  7. Make your code independent of the Communication Mechanism between layers. This allows us to change/scale the communication layer as required and the code is clean. Always remember cleaner code is easier to scale than spaghetti code :-)
  8. Use resources carefully. And its best to cache expensive resources and quickly return those back to the pool instead of holding onto them for a long time.
  9. Keep the Transactions as short as possible. And group similar things into a single Transaction.
  10. Same goes for any locks you hold in the code, like Synchronized Blocks – keep them as small/short as possible. Also synchronized blocks are not the only solution for shared data access. There are other ways as well, many of which are available in new concurrency package in Java.
  11. Cache as much as possible. But don’t make your code do that. Keep the cache transparent to your code – Aspect Oriented Programming (AOP) can help a lot in these scenarios and/or cross cutting concerns.