I have an application that runs on jboss 5, uses struts2 ,JAXB, Apache HTTP client to contact other servers in business logic, oracle db for some select operations and insertion of logs.There is a heavy use of concurrent hashmap for session management,there is lot of static data being cached in servletcontext too .the TPS that i get now is around 150 TPS and the requirement is to get 3000 TPS,
1. is this realistic?
2. what are the things i can start looking at?
The first step with performance improvement is always to run a profiler, and find out where your code is actually spending the time. It does no good to try and improve your algorithm if you are always waiting on disk access.
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
3000 TPS with one server node? that does not sound very optimistic. there are limits on harware too - sockets a server can use, ram, cpu ... 150 seems to be pretty good.
most of the profilers i have used work better with java 6, so maybe you could look at migrating.
when we had we used selenoium to make a test suite for the web app, a few unit tests, migrated to java 6, then ran the suite again. we did not have any issues except for some entries in the jvm as we use a hsm server ...
we use a lot of cached data too - in static hash maps - they are okay as long as they are load once or load occsaionally read many times. but you mentioned " concurrent hashmap for session management,there is lot of static data being cached in servletcontext"
do you start any threads/ java timers or use jms in the same jvm -> should be fine as long as other threads dont write to the same context or maps. again a profiler would help if there are issues.
Another important step in improving performance is to identify measurable requirements. Although performance improvement often starts with somebody complaining that something "feels slow", when it comes time to do the work, you need a measurable goal, such as "at most N seconds to render a page", or "at least N transactions per second", etc. Without one, it's hard to compare different approaches and hard to know when to stop.