From below two scenarios which can be happen and which cannot? Please help me understand:

Scenario 1: Throughput is very high and hits per second is very low

Scenario 2: Hits per second is high and throughput is less

  • Can Scenario 1 (Scenario 1: Throughput is very high and hits per second is very low) is possible in Real Time? – Shruti Srivastava Apr 8 '19 at 18:07

Throughput: This is the number of requests that are successfully executed/serviced per unit of time. For example, if the throughput is 50/minute, this means that on your server, per minute, 50 requests are executed successfully (accepted, processed and responded properly).

Hits per second: This is the load with which the server is being hit. It means x number of hits are sent to the server every second.

Both the scenarios you have mentioned may require thinking for a moment that there's something fishy if they both use a different unit of time. Because JMeter sometimes displays throughput in per minute and sometimes in per second, whereas the hits per second is always per second.

In case of throughput; the higher the better. This means that your server is capable of successfully executing that many number of requests per unit of time.

Lower the difference between throughput and hits per second (in same unit of time) the better for your system. If the difference is high that means that your server isn't performing well enough.

In short hits per second is the total load on system and throughput is part of that load going successfully and the difference is the failed requests.

  • That's nice but how do I test any HTTP request online about its performance. – Maveňツ Jan 10 '17 at 8:23
  • Sorry, I didn't understand what you are trying to ask. – IAmMilinPatel Jan 10 '17 at 8:25
  • I was asking suppose I have a rest API which I want to test like 2000 clicks/second so that was my question how do I test any HTTP request online about its performance. Upto how much payload can my specific server can handle? – Maveňツ Jan 10 '17 at 9:53
  • There is no 1 rule of thumb for that. You won't get 1 fix number for server's capability to handle payload. You need to figure out how much load is expected on your URL and work your way around it to identify if your server can handle it or not. – IAmMilinPatel Jan 10 '17 at 10:22
  • 1
    @Gattsu If using linux, it's pretty easy to write a curl script to make a bunch of request to your endpoint to simulate a load. You could also write a client application that sends a few thousand requests at a time. – Tabrock Apr 16 '18 at 17:44

Basically, throughput is number of requests per second that your server can handle. Thus as far as the throughput is concerned, the larger the better! Both the scenarios that you've mentioned contradict to the definition of throughput. If through is high that signifies that your server can handle large number of requests per second.

Scenario 1 may be because you're applying less load but your server can handle large number of requests per second.

Scenario 2 may be because now you're applying huge load, more than what your server can handle properly in a normal condition. Thus, throughput decreases as load is kept on increasing.


Request/Hits per second - The number of request received by the server. For example, the server can receive 10 requests per second, and the server send the response for all the requests in a second or not .But, here requests per second is 10, since it never bother about the response

Throughput - It considers the response status. If 8 requests are successfully responded in a second and other 2 are served after some time, then it gives you only 8 per second out of 10 requests per second.

At the end, RPS is nothing but the number of requests received by the server, and Throughput is nothing but the number of requests it was able to serve in a second or number of requests server is able to respond in a second

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.