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

Trace senstive to latency still can we recomend to application team a nytuning opportunity

shakti_sareen1
Contributor

@Tomasz Szreder, @Gary Kaiser- Help me experts with one more trace having communication protocol as MSSQL which looks chatty and prone to latency impact.

This trace related to fetching and generating report hence payload looks bit high and chatty too. It a specific transaction which run and display the report.

Can you just have a look on the same and provide some expert advise. According to me I can see in the trace same sort of queries many times in occurrence for example:
MSSQL:BATCH SET FMTONLY ON select BATCH_NUMBER,GL_YEAR,GL_MONTH from JCFJV WHERE 1=2 SET FMTONLY OFF
Also server payload bytes linked to all threads very less around 100 bytes. Is there any we can recommend something which can help them reducing app turns 23,550.

Reason for asking you some recommendation because after prediction this 79 seconds increased to 1200 seconds approx. which is scary.

If nothing possible then system need to be local and cannot be migrated over latency of 64 ms.

clientside-tracewip-variancejvreport-copy.zip

6 REPLIES 6

ulf_thornander3
Inactive

Hello @Shakti Sareen

Do you have the chance to share the trace so that we can have a look at what is going on?

I have requested dynatrace team to help me in attaching the trace which is of 1.5 mb after compression and on this portal we cannot add attachment more than 1 mb. I am hoping to get this trace online soon @Tomasz Szreder kindley help here

I managed to upload the trace. Indeed, this is a large one, 15 MB after unzipping... I believe you will need to focus on a part of the trace only to draw useful conclusions.

Tomasz_Szreder
Advisor

I'm wondering if it's not a similar case to your earlier question? Since the application is accessing the DB server very frequently, even minor latency increase will impact overall performance significantly. This is exactly what RTP is telling you.

https://answers.dynatrace.com/comments/158928/view.html

The recommendations seem similar - make the application request data from server only when necessary and avoid executing many simple queries. Just my 2 cents 🙂

In JIRA ticket I mentioned about:

"This trace is from the same application we are working from last 1 week together. Till now the trace I shared was related to prelogin and some repeated queries and we found issues to be rectified".

I have mentioned much content in the question being asked. Hope it will be relevant to be answered.

It is the sheer number of requests and responses that's important here - the whole operation involves 23,000+ app turns, each after another in a sequence.

Just imagine it - if each operation takes 1ms, then the whole task lasts at least 23000*1 ms = 23 seconds.

If the server is in a remote location and each request and response from the server takes 15 ms, then the report generation will take 23000*15ms = 345 seconds. This is very rough maths.

- Avoid many app turns by using stored procedures, or

- Run jobs in parallel in threads

Hope this helps your application developers improve performance of the app.