You create a web application. The application becomes popular and you start getting a lot of traffic. Traffic which you had not imagined. The drawback … the response time increases, the threads on your web servers start building up and the application starts to get on its knees.
Under these circumstances what most organizations would do is to start looking externally at promise the world tools like terracotta, memcache, in-memory data grid, etc etc.
Nothing wrong with that and probably you would need them anyway but before getting there it might be worthwhile to look internally to see if there is stuff which could be done with the application. This includes
- Caching – right size the existing cache, if it is present, optimal utilization of cache by not putting frequently changing data in cache, not using cache for storing temporary transactional data. If you do not have a cache already consider using one.
- Profiling the performance hot spots and other candidates for looking out at memory leaks or unnecessary logic.
- Moving computation from the DB to the application layer – Many applications use the db for performing processing logic, thus saturating the db cpu.
- De-normalize db tables depending on the functionality for faster access.
- Asynchronous where possible – Queue up jobs which are not critical to the main flow of the use case
- RIA, Offline data access candidates where possible so that the network traffic is reduced, reduce http traffic
- Schedule batch jobs for non peak hours
- CDN for static data
- REST based URLs where possible so that URLs can be cached, this could be for scenarios where the same request instead of hitting the server picks up the entire generated page from the cache