Response time Vs LatencyVs Processtime

Latency is the delay incurred in communicating a message (the time the message spends “on the wire”). The word latent means inactive or dormant, so the processing of a user action is latent while it is traveling across a network.
Changes in latency are typically unavoidable through changes to your code. Latency is a resource issue, which is affected by hardware adequacy and utilization.
Example: The latency in a phone call is the amount of time it takes from when you ask a question until the time that the other party hears your question. If you’ve ever talked to somebody on a cell phone while standing in the same room, you’ve probably experienced latency first hand, because you can see their lips moving, but what you hear in the phone is delayed because of the latency.
Response time is the total time it takes from when a user makes a request until they receive a response.
Response time can be affected by changes to the processing time of your system and by changes in latency, which occur due to changes in hardware resources or utilization.
Example: The response time in phone conversation is the amount of time it takes for you to ask a question and get a response back from the person that you’re talking to.
Processing time is the amount of time a system takes to process a given request, not including the time it takes the message to get from the user to the system or the time it takes to get from the system back to the user.
Processing time can be affected by changes to your code, changes to systems that your code depends on (e.g. databases), or improvements in hardware.
Example: The processing time in a phone conversation is the amount of time the person you ask a question takes to ponder the question and speak the answer (after he hears the question of course).
In these terms:
Latency + Processing Time = Response Time
In many cases, you can assert that your latency is nominal, thus making your response time and your processing time pretty much the same. I guess it doesn’t matter what you call things as long as everybody involved in your performance analysis understands these different aspects of the system. For example, it is useful to make a graph latency vs. response time, and it is important for all the parties involved to know the difference between the two.