If you have concurrency set at 1, there's no difference between those two. It begins to matter when you have more than 1 request performed simultaneously.
Let's look at an example of what I get on my localhost:
ab -c 1 -n 1000 http://localhost/
will give:
Time taken for tests: 3.912 seconds
Time per request: 3.912 [ms] (mean)
Time per request: 3.912 [ms] (mean, across all concurrent requests)
This means that 3.912 seconds were needed to perform 1000 requests one by one. So a single requests needed 3.912 seconds / 1000 = 3.912 ms on average.
Now let's beef up the concurrency level a bit:
ab -c 10 -n 1000 http://localhost/
Time taken for tests: 0.730 seconds
Time per request: 7.303 [ms] (mean)
Time per request: 0.730 [ms] (mean, across all concurrent requests)
This time instead of 3.912 seconds we need only 0.730 seconds to get the job done. We've performed 1000 requests in 0.730 seconds, so one request would take on average 0.730 seconds / 1000 = 0.730 ms (last line). But the situation is a bit different, as we are now performing 10 requests concurrently. So in fact our number here is not reflecting the real time it takes for one request to complete. 0.730 ms * 10 (number of concurrent requests) = 7.303 ms. That's the time it takes on average for a single request to complete if it were executed non-concurrently (or more correctly, in an isolated manner at the current concurrency level).
The last number you see (0.730 ms) is used to tell approximately how much the total time would increase if you've added 1 request (-n 1001) using current concurrency level -c 10 (well at least theoretically it is so).
The 7.303 ms gives you an overview of how long a single isolated request would run.
The change you see between example -c 1 and -c 10:
[-c 1 ]: Time per request: 3.912 [ms] (mean)
[-c 10]: Time per request: 7.303 [ms] (mean)
means that a single request does run faster if it is the only one being executed -c 1. If there are multiple requests -c 10 competing for resources, a single request will take longer to complete. But if you take into consideration the fact that you are performing 10 such requests at the same time, in this 7.303 ms you deal with 10 requests instead of 1.
So as a measure of delay for a single request - the 7.303 ms is more useful. But as a measure of performance - 0.730 ms is more meaningful. In fact as 0.730 ms < 3.912 ms you see that you will be able to serve more requests per second on aggregate if you allow for 10 concurrent requests.
