cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

This product reached the end of support date on March 31, 2021.

What is Sync time, CPU time , Suspension time and IO in AppMon?.. How is it divided for total Response time?

vishwas_jain
Newcomer

I am getting high synv time for some requests. test was ran for 1.5 hours but for 5min busy thread count was high. Trying to find out the reason.

6 REPLIES 6

vishwas_jain
Newcomer
  1. @suresh K Can you help me out?

JamesKitson
Dynatrace Leader
Dynatrace Leader

It seems you posted this question twice. Note that both would be applicable in the AppMon forum. I added an answer there:

https://answers.dynatrace.com/spaces/482/dynatrace-open-qa/questions/198202/what-is-sync-time-cpu-time-suspension-time-and-io-1.html

Yes I found above page already. but it does not give me proper understanding.

Take a look at Andi's answer on the question:

https://answers.dynatrace.com/spaces/148/uem-open-q-a_2/questions/101548/meaning-of-breakdown-by-execution-time.html

"Whenever we see the method executed we capture in which state the method is, e.g: is it executing code (=CPU), is it waiting for something (=Wait), is it waiting for a sync bloc (=Sync) or is it doing something else (=IO)... The caller breakdown shows you who actually called that method"

I think that's the extent of what I can help with here.

JamesKitson
Dynatrace Leader
Dynatrace Leader

User recreated question in AppMon forum:

https://answers.dynatrace.com/spaces/148/uem-open-q-a_2/questions/198222/what-is-sync-time-cpu-time-suspension-time-and-io-2.html?childToView=198227#answer-198227

Joe_Hoffman
Dynatrace Leader
Dynatrace Leader

Vishwas, I'm assuming your question deals with AppMon. I assume when you say "Synv" you mean "Sync".

Sync time is the time measured by AppMon when your worker thread is blocked waiting to enter a sync code block. Sync code blocks are used by the programmer to designate critical code sections that must be executed by only one thread at a time. Take the example of creating a new user. If two users try to create a login name with "Fred" at the same time, both might end up with this login name, which must be prevented from happening. The easy way to prevent two users from both getting "Fred" as a login name is for the code author to wrap this critical code section in a sync block which ensures only one thread executes it at the same time. The second thread waits until the first thread is done, then the second thread executes the critical code section and is told "Fred" is already taken. If a sync code block takes too long, and there's a lot of threads trying to execute this critical code section, then it can start to show up as a critical blocker in productivity of the entire system. Having a worker thread spend a brief amount of time in sync is OK, but it should be as lean and quick as possible to avoid unnecessary blocking of other threads.

In AppMon, I suggest you drill into the purepath and find out what method(s) are creating sync time and inspect the sourcecode of these methods for what they are doing. Is there possibly a faster way to execute them to minimize the work being done in the sync block, thus speeding up the execution of the sync protected code section? If this is 3rd party code causing the problem, might be worth talking to the vendor, posting on a forum your problem. Perhaps there's a different way to use the 3rd party functionality to minimize sync time. The Response Time Hotspots dashlet in AppMon is a great way to see how much sync time is being accumilated and by what tier and what code section. Click on the Sync color and the Method Hotspots dashlet will open and showcase the offending code.