views:

476

answers:

4

Can someone please explain the correlation between requests per second and response time? Which are you trying to improve at first? If your competitor offers less 'requests per second' on his most used functionality then you, is your application performing better in terms of end-user performance?

+1  A: 

It all depends on what sort of load your system will be under.

If you have millions of users then you need to handle more requests per second possibly at the expense of response time otherwise users may not be able to connect when they want to.

However, if you are only going to have 30 users then it's more important to them that your system responds quickly than it being able to handle a thousand requests a second.

Garry Shutler
A: 

If your competitor offers less 'requests per second' on his most used functionality then you, is your application performing better in terms of end-user performance?

I wouldn't agree with that. Look at Google. They make thousands of requests a second - hell, I think it's something like 100 million per day and 3 billion per month.

To answer your question, I think response time is more important than requests per second. Sure you can optimize/minimize the number of requests made, but if your product scales to handle unlimited requests (just by throwing more hardware at the problem) then I think that is more valuable.

Steve Willard
+1  A: 

Requests per second may be high while offering an awful user experience. You might have a lot of users buying thousands of concert tickets per second but the response time for each user is over 30 seconds.

For a high performing, enjoyable web site, you need to have a high number of requests per second and a maximum response time. As a user, I like 5 seconds or less.

Zan Lynx
I didnt got it at the moment: shouldnt be the response time and requests per second be inversely proportional? So if your response time increases from 3 to 30 secs per requests, the requests per second should decrease. But they still can be high in eyes (if i dont see the reponse time too) right?
Mork0075
No. If part of the processing was writing the requests to a USB key, throwing it across the computer center to an intern and signing all the data with a secure private key? An 8GB USB key could hold a million requests to be processed in 2 minutes but the response time would still be 2 minutes.
Zan Lynx
I dont understand this example, can you please try again?
Mork0075
+7  A: 

Can someone please explain the correlation between requests per second and response time?

Think of this situation as if it were a gas station. Cars arrive at various intervals and occupy a pump; they spend some time filling up, and then they leave.

  • Each car that arrives and occupies a pump is a request.
  • The time it takes to fill up is your response time.

You can improve things in two ways:

  • If you add more pumps, you can service additional cars at once because there will be more capacity.
  • If you make all your pumps faster, you can service more cars over time with the same number of pumps, because each car will finish sooner.

Which are you trying to improve at first?

That depends. Do you want to serve people faster (improving their experience while making some others wait) and thus more people overall, or do you want to serve more people at once (at the possible expense of request time)? Ideally, get both metrics as good as possible.

John Feminella
Same point as me but with a nice analogy :)
Garry Shutler
Very nice, thanks. If i improve my pumps (look for inefficient algorithms in the software, introduce caching, fewer sql requests) and verify the improvements by gas station throughput, this also implicates that every 'servicing a car' is getting faster - right?
Mork0075
Yep; if you spend less time processing a request, you are effectively serving more cars at the same pump over time.
John Feminella
So do you think its fine to know the requests per second of your 'competitors', state something like '20 RPS would be nice' and try to reach this goal in a quality assurance step or is this kind of compairing apples with oranges? The goal of this QA step is to say 'our performance is fine'
Mork0075
Unless your products are close to Internet commodity status (e.g. searches), I'd say that's apples-to-oranges. If you really want to know how you're doing, do load testing to get your system near the threshold, then add a real user and ask them how they feel about the site's performance.
John Feminella