Synchronized/Threads - Checking for Bottlenecks
Hi Everyone,
We have an application that uses multiple threads to perform a calculation. When any method has found a possible "Solution" it writes to a database.
We want to track the performance of the application and the number of calculations that it has performed, therefore, we have implemented a single class which has Synchronized methods to count the number of calculations performed.
If a Thread is currently using the "Synchronized Counter Method" and another method tries to access it - it waits until the Thread has finished. What I would like to find out is how many "waits" are occuring. I.e. is the counting aspect slowing down the application by causing a bottle neck.
With approximately 680 calculations per minute. This is a concern.
Is there anyway determine if these "waits" are occuring? Due to the nature of the program it is not possible to switch off the counting and switch it back on again and compare the executing time.
Kind regards
Angus
We have an application that uses multiple threads to perform a calculation. When any method has found a possible "Solution" it writes to a database.
We want to track the performance of the application and the number of calculations that it has performed, therefore, we have implemented a single class which has Synchronized methods to count the number of calculations performed.
If a Thread is currently using the "Synchronized Counter Method" and another method tries to access it - it waits until the Thread has finished. What I would like to find out is how many "waits" are occuring. I.e. is the counting aspect slowing down the application by causing a bottle neck.
With approximately 680 calculations per minute. This is a concern.
Is there anyway determine if these "waits" are occuring? Due to the nature of the program it is not possible to switch off the counting and switch it back on again and compare the executing time.
Kind regards
Angus
CEHJ
You don't need anything special. Since you're the one creating the threads, simply keep a count and record the time when each thread reports it's finished
...and you can also record the time *before* it calls the synched method
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Wow... was not expecting such a response... thanks.
You have provided me with some very good ideas on how to remove the bottle neck. much apprecaited.
The application is very complex and changing the handling of threads will involve significant development work. Therefore what I would like to establish before making any changes is that indeed this is creating a bottleneck (& a significant one).
I have tried using the suggestions, e.g. time etc. but was unable to distinguish if there was indeed a bottleneck as there are 40+ Threads. What would be extremely useful is to be able to catch the 'wait' Thread when a thread tries to access the count method. And therefore after processing is finished, establish the number of waits (and maybe how long).
Once again - cannot thank you guys enough for replying to my query.
You have provided me with some very good ideas on how to remove the bottle neck. much apprecaited.
The application is very complex and changing the handling of threads will involve significant development work. Therefore what I would like to establish before making any changes is that indeed this is creating a bottleneck (& a significant one).
I have tried using the suggestions, e.g. time etc. but was unable to distinguish if there was indeed a bottleneck as there are 40+ Threads. What would be extremely useful is to be able to catch the 'wait' Thread when a thread tries to access the count method. And therefore after processing is finished, establish the number of waits (and maybe how long).
Once again - cannot thank you guys enough for replying to my query.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Sorry CEHJ I miss understood you.
Thanks for the code - it has worked.. Indeed I have a bottle neck. Damn. Back to the drawing board... this is going to be a long night.
ALL - Once again thanks for the tips.. together you have given me lost of food for thought.
Thanks for the code - it has worked.. Indeed I have a bottle neck. Damn. Back to the drawing board... this is going to be a long night.
ALL - Once again thanks for the tips.. together you have given me lost of food for thought.
> Indeed I have a bottle neck.
Yes, any synchronisation will introduce a bottle neck.
Even if they never have to wait it still adds overhead to the method call.
Yes, any synchronisation will introduce a bottle neck.
Even if they never have to wait it still adds overhead to the method call.
This is potentially the only synchronized method you need your 'calculator' to call:
public void synchronized countCalc(YourRunnable calculator) {
calcsDone += calculator.getCalcsDone();
}
The time spent in that method will be negligible
public void synchronized countCalc(YourRunnable calculator) {
calcsDone += calculator.getCalcsDone();
}
The time spent in that method will be negligible
Time spent in the method is not the only issue, just calling a synchronised method adds overhead.
The suggestion I posted above would remove any need for synchronisation (as well as the need to call any method).
The suggestion I posted above would remove any need for synchronisation (as well as the need to call any method).
>>just calling a synchronised method adds overhead
The overhead of calling that method is negligible
>>The suggestion I posted above would remove any need for synchronisation (as well as the need to call any method).
...and would be more difficult to implement, quite apart from possibly causing much worse overheads by having to retain references to all runnables until the last one finishes or the overhead of creating a polling thread
The overhead of calling that method is negligible
>>The suggestion I posted above would remove any need for synchronisation (as well as the need to call any method).
...and would be more difficult to implement, quite apart from possibly causing much worse overheads by having to retain references to all runnables until the last one finishes or the overhead of creating a polling thread
amacfarl,
try it out and see for yourself :)
Do some benchmarking with you current code, and then comment out the call to the synchronised method, run it again and see the difference.
try it out and see for yourself :)
Do some benchmarking with you current code, and then comment out the call to the synchronised method, run it again and see the difference.
:-)
Thanks amacfarl, let me know if you want to discuss my suggestion further it should give you a decent improvement in performance.