It sounds like you may be using Gatling for your testing. Their documentation is unfortunately a little light with respect to these definitions: http://gatling.io/docs/2.0.0-RC3/general/reports.html.
At a high level, latency is how long it takes for data to travel from one point to another. Response Time is how long it takes for data to travel from point A to point B and then back again. Like when you tell a web server you want to visit a page. You send a request to the server (SYN), the server receives your request and sends you the page (SYN-ACK), and then you acknowledge you received the page (ACK) which allows the remote server to set up the connection once it sees your ACKnowledgement. Look up TCP 3-way handshake for more info on response times.
I will try to expand on the specific items you have listed to better explain:
- Response Time Distribution: This chart shows you the percentage of all requests made during your test run on the Y axis. It will include both successes and failures. All of the Y values should add up to 100%. The response time (the time it takes to request the page and send data back to the server to acknowledge you received it) is on the x axis. As you increase load on the server, you should see the data on this chart move farther to the right (response times will get slower).
- Response time percentiles over time: This is similar to Response Time Distribution, but it shows you the data over a longer period of time to assess how your system behaves when under a sustained load. For example, 200 users accessing various web pages over the course of 5 minutes. You want to analyze the high response times that appear in this page and see if they are expected and how they change based on the duration of load and number of users. Sometimes servers will see lots of failures after a specific time period based on timeout configuations, keepalives, etc. Depending on what you are testing, you may have 24hr or even 1week long sustained load tests to run to see how long it takes for the server to fail under load and how it recovers from the failure.
- Latency: This is the time it takes for the network packet to travel from the source (the server under load) to the destination (your gatling tool, or the hardware it is monitoring to be specific). When the network is under heavy load, it will take longer for packets to arrive and affect your page response times, so it's an important metric to consider when analyzing overall results as it can show network bottlenecks that may be impacting your server and/or your test results.
- Latency percentiles over time: This basically tells how long it takes to receive the first packet for each page request throughout the duration of your load test. If you look at this chart in the Gatling documentation, the first spike is just before 21:30:20 on the x axis and tells you that 100% of the pages requested took longer than 1000 milliseconds to get the first packet from source to destination, but that number fell significantly after 21:30:20.
- What is RPS: In Gatling, this is "Requests per Second". The number of times you make a request for a resource from the server per second. For example, if you simulate 200 users accessing one file on a server all at the same time once a second, you'll have 200 requests per second. Like Jay said, however, this could be any number of definitions in other tools.
- Latency against Global RPS: By now, you may see a pattern here. This is showing you how latency is affected based on the number of requests you are making per second in your test. For example, when 160 resources are requested per second, it will take 200 milliseconds for the data packet to transfer from the source (web server) to the destination (test tool, or whatever hardware the tool is monitoring).
- Response time against Global RPS: This is the same as Latency against Global RPS, but instead of measuring latency, it measure all responses per second you have configured in your test.
For your final question about performing UI actions, you can certainly invoke UI actions upon accessing a page and put that single page under heavy load to see how it performs. It depends on what you are specifically load testing. Load testing a server is different than load testing a web application because of the UI involved and perhaps multiple different servers involved.