DX Application Performance Management

Hi All,

We have port mirrored the data of Web servers to Tim.
The request flow is User request >> Load balancer >> web server>> App server >> Db(optional).
Response flow is DB>>App>>WEB>>LB>>User.
We want to know, at which point is the response time calculated in CEM?
Is it at the web server level where we port mirrored the data or anywhere else ?

Thanks,

Chandrasekhar.

This is from the CEM 4.x manuals but shows what I think you are asking. 

Hi Hal, 

My doubt was if we mirror traffic at Web server level(Place Time between LB and Web servers), will we get response time of complete network as mention in the diagram as CEM Transaction Time?

Thanks,

Chandrasekhar.

Adding JMertin  but that should be fine.

This is covered in https://docops.ca.com/ca-apm/10-3/en/administrating/cem-configuration/networking-alternatives-for-cem/about-cem-insertion-locations

It has the following

Between the Network Load Balancer and the Web Server

Insertion location E, between the network load balancer and the web server (or servers), often provides visibility into the client IP address. In order for this to occur, "preserve source address" must be enabled in the network load balancer if it is acting as a proxy. Insertion location E almost always provides visibility into the server’s IP address.

If the network load balancer uses persistent connections, the load on the TIMs is decreased when the TIMs are located here. The decrease in load is a function of the reduction in open connections, which might be significant. If the network load balancer terminates SSL on behalf of clients and does not re-encrypt the traffic, then the load on the TIMs is further reduced in nearly all cases by a significant amount.

Because the TIM uses the server IP address for evidence collection, there are significant advantages to using insertion location E. However, insertion location E has some disadvantages that insertion location D lacks. Since there might be many web servers, there might be many insertion locations. This might make it impractical to use taps for insertion location E.

Insertion location D and insertion location E are functionally equivalent when port mirroring is used. In many cases spanning a virtual LAN (VLAN) is all that is necessary to use insertion location E. For insertion location D, simple port mirroring might be sufficient.

Note: For more information about TIM and network traffic, see TEC1693123.

Dear Chandrasekhar.

  I have responded to your question and referred you to the documentation. So marking as answered. You may post follow-up questions as needed but the last reference should cover the question

Thanks

Hal German

Hi Hal,

I went through tec1470237, according to this document, "CEM monitors transaction time on the switch (monitored network interface; where CEM TIM/MTP appliance is installed)." That means, the time between the first packet of request arrived at Switch to the last packet of response identified at Switch where port mirroring has been configured. Am I correct?

Or is it calculated at user desktop from and to ( Using Packet timestamp or something)?

Thanks,

Chandrasekhar.

Traffic to the TIM should see the HTTP/HTTPS request and response between the customer and the web/app server and that should be used to determine the response time. 

By default the sender applied timestamp. If the sender is the Switch, then it's the switch's provided timestamp.

But in terms of TIM interval, it is when the TIM sees the data. 

There will also be a small influence due to the SPAN infrastructure, but it is really tiny and can be ignored.

The overall transfer times are limited by the slowest speed in the entire flow. Imagine a road (being the network cable between A and B), and you have 50 cars on it, driving in average 90Km/h - suddenly one decides to go down to 50Km/h. All cars behind him will be that slow from now on.

Roughly speaking, it is the same on a network. The slowest component will determine the speed of the entire data-flow from A to B. And using the time-stamps, we see how fast a packet was.

The time to first response -> to the last packet of the response enables us to simply know how long the right side took to compute and send out the response. We can say if the web/app-servers or the network is slower

Hi Joerg,

Thank you for the information. If a user initiates a transaction, packets will be generated carrying the generated timestamps(at User desktop). But, when we port mirror the same packets when they reach switch to TIM( considering TIM is connected to the same switch), do the timestamp of the packets change or they would be same as they were at user desktop level? 

Regards,

Chandrasekhar.

I will have to pass here, as I don't know which timestamp the TIM uses. SeeTransmission Control Protocol - Wikipedia  

I will think out loud below: Important for the TIM is the start-time and end-time, to determine the transaction duration.

I think that the TIM uses the Tx timestamps as found the packets linked to a specific transaction. I suspect that the TIM however also uses it's own reception time-stamps for start and end of a transaction because it requires to align all received packets to the same time-origin.

I'd need to ask some of the developers for confirmation though.

Hi Joerg, 

Thank you. Actually our SLA is related to transaction time between user to Application backends and back. If the response time is calculated at Switch level that may not be considered as it might ignore time span between user and switch. That would be very helpful if you confirm on this. Waiting to hear from you.

Thanks & Regards,

Chandrasekhar. 

First of all - SLA is a contractual value. So, not a Monitoring baseline :}

Second, to your question, it does not matter how long the transfer times from SPAN to TIM are, they are not taken into account for the time calculations as these are going to exist for both directions, and because they are so small, can be ignored (this data is used solely for time to first response computation). The transaction time data etc. is extracted from the TCP/IP packets themselves.

Asking JMertin to weigh in.