It depends on a lot of factors. Does your testing just exercise the servlet/JSP container?
Is testing based on HTTP 1.1 persistent connections?
If it only tests the servlet container here are some hints.
You should probably give the JVM more memory by conventional wisdom (although I'm doing some investigation in this area at the moment in something related) and increase the available listener instances - a minimum of 5 and a maximum of 75 is actually not much if you are simulating more persistent connections than 75.
A servlet performance report http://www.webperformanceinc.com/library/ServletReport/ provides some tips on their performance configurations and results of testing.
If this is still not enough speed, also consider turning off the reverse lookups if you can get by without resolved names in the access logs.
That is a starter I hope.
Thank you for your response.
We increased the number of CPU in Oracle database. Also changed web server config as
Right we can reach 15 hits per second. And the reponse time is around 3 seconds per page.
OK. Looks like there are some bottlenecks in the areas you have addressed. However, I sense there must be some other bottleneck. You have some fairly powerful processors at your disposal, yet a transaction is taking 3 seconds. This is a large amount of time. I would monitor your CPU capacity under the load you are imposing - build/install "top" on your Solaris system and check the levels of processing on the CPUs - or use whatever server monitoring tools you have to achieve the same.
If CPU levels are not at 100% (assuming the DB is not on the same system), then you are not at saturation and the bottleneck is not caused by being CPU bound. You should look for deadlocks or co-ordination events in your application that might cause them to wait for response in the transaction chain. This might include tuning JBoss for good CMP if you are using CMP. It might also involve timing JDBC transactions and determining if there are any issues there.
If it is CPU bound, I would start looking for the source of such CPU intensity.