I have a plain web application using Tomcat 5.5 (no application server). In the server side, I am trying to achieve multitask, get data from databases in parallel. Now it works, but problem is, I didn't see any performance improvement.
Now, my questions are: 1. using multithread in server side, is it right direction ? 2. or the database (sybase) not allow to access table in parallel ? 3. or connection manager has some limitation ?
Joined: Mar 22, 2005
1. using multithread in server side, is it right direction ?
A servlet environment is inherently multi-threaded, unless you take steps to prevent that.
2. or the database (sybase) not allow to access table in parallel?
All serious commercial databases allow simultaneous access. That by itself may or may not lead to increased performance; e.g. on a single-CPU system handling multiple processes involves a small switching overhead, and, of course, the sum total time of executing two processes will be at least as long as executing those two processes sequentially.
3. or connection manager has some limitation ?
Depends on how it's done - are you using a connection pool with multiple connections?
Also, how did you establish that there was no performance gain?
Yes, the servlet engine is multi-threaded, but in my business logic, could I still use multi-thread to improvement performance?
Using more threads instead of 1 will not improve performance on all the systems and all type of machines. Increasing the number of threads will increase performance when there your system does work that is not cpu bound but at some places waits for an external input or blocks on I/O or waits for locks i.e. essentially your cpu is not completely utilized. If the above is not the case then in all probability your performance will go down by increasing the number of *active* threads as there will be thread scheduling overhead i.e. OS will try to suspend the executing thread(or threads in a multi-processor system) to give some time to the waiting threads and hence even if a thread is computing, it will be made to wait. So, the latency of the system will rise and hence the throughput will go down.
While I agree with the gist of Nitesh's post above, it really isn't relevant here because the system is in all likelihood not CPU-bound, but I/O-bound. Edward said that it involves significant DB accesses, which is I/O as far as the servlet container is concerned.
Generally, simultaneous accesses to a servlet container will improve throughput (although not single-process performance, obviously).
Ulf: Generally, simultaneous accesses to a servlet container will improve throughput (although not single-process performance, obviously).
I did not get this statement. Access to a servlet container is always simultaneous/concurrent, isnt? However, the question is whether spawning new threads from within processing a request will boost performance or not? I *think* it depends on the servlet container configuration also. If the server already has a lot of *active* threads then spawning new threads will probably not improve performance however, if the cpu is under utilized then it will definetly. Now, the problem is the number of threads running inside tomcat will *probably* be governed by the load on the server and by the number of applications (though i am not sure about this), so how can one optimally configure a thread-pool to really make use of the parallelism in the request processing and thus improve performance? Without profiling the application it will really be tough to say that whether spawning new threads to make different Database calls will aid performace. It may be that the bottleneck indeed is database but how much will it be improved by processing multiple database calls parallely is something that can only be speculated untill we have profiling results.
IMHO, we should move this post to Performance forum.
Joined: Mar 22, 2005
Ah, I hadn't read the question as being about creating threads in the servlet container, but upon closer reading I think it is.
Creating threads in the servlet container itself isn't much of an overhead, certainly not when compared with the time needed to access a database. I guess it comes down to point #2 about whether the database itself is likely to exhibit better performance.
I'll move this to the Performance forum.
Joined: Jun 26, 2002
You are currently trying to optimize without knowing where your bottleneck is. This is like putting a cast on a patients foot without first asking what his problem is. It might work, but more likely the patient will still have his cough and limp around in a cast too. [ January 31, 2008: Message edited by: steve souza ]