How to scale a J2EE application?

Some quite simple and basic points.

• Get rid of single point of bottleneck : There can be any point across the whole architecture of a layered lava application which can act as a constraint from the application to scale . This point is know as the single point of bottleneck, Single point of bottleneck can be any service, resource or server that all the request shares and goes through, examples can be connection pools, singletons, databases, JMS queues, web services etc. First we need to identify that constraint and then identify the ways to remove that constraint. This should be done till we end up finding another constraint.

 

• Do not use databases for everything : Do not persist high volume stuff which is of very little return like logging info, http session state (there are much better performing options for caching stuff like these) into the database. Put only those things which are persistent and transactional.

 

• Get rid of single point of failure : Design for high availability and fail-over support like clustering the servers/devices and this will eliminate single point of failures making the application more scalable.

 

• Do the horizontal scaling : Any resource which can become a part of a pool of resources can be scaled horizontally. We can do either perfectly horizontal scaling for web servers (where each server can behave without knowing anything about any other server) or can do clustered horizontal scaling for application servers (where we need cluster management and so the scaling is not completely linear). Look out to scale vertically only once if you hit the ceiling to scale horizontal.

 

• Make your database scalable : When using ORM, association of tables using non-indexed columns to retrieve object properties will not allow the database to scale. Always evaluate indexes when coming up with the mapping and revisit it quite often. Partition the database tables either horizontally or vertically to keep them manageable. Try to avoid using manually crafted named SQL queries. If used right it might improve the throughput (which might be the very reason for their existence) and if done wrong (with too many tables, non-indexed columns etc) it can be very detrimental to the scalability of the application.

 

• Do not use AJAX for everything : AJAX means more requests coming to the server and that too more quickly, thus if not used in the right way can create havoc on the web and application servers. So we have to be careful where we use it, make sure the AJAX requests contain session id to prevent from creating a new session for each request and size of the reply should be kept to the minimum.

 

• Optimizing the life of sessions : We should not keep sessions in memory any longer then they should be. Session memory size should be kept to minimal by keeping keys rather then persistent object themselves.

 

• Tuning the garbage collector : Doing this will improve the throughput which will eventually make the application more scalable. It is not a perfect science and there is no exact formula to tune it and might require several tries before we get to something which works for the deployment and with each new deployment, we might need to tweak it again.

 

• Connection pooling : No doubt it has to be done to avoid the expense of creating and destroying the connection for each request (which can be somewhere around 250 ms) and if done right it helps the application to scale as it will improve the throughput. But the important thing to consider, is the pool size. It should neither be kept too low otherwise we might end up with pool contention even during normal loads nor should be too huge to take up all the memory.

 

• Do not try to pool everything : Connection pooling is fine but do not get overboard with the idea of pooling. Do object pooling for only those objects which are expensive to create.

 

• Make the calls asynchronous wherever possible : Asynchronous calls does not block the client request and prevents a thread from being idle and wait for response.