Comments on: Calculating Throughput and Response Time http://javidjamae.com/2005/06/20/calculating-throughput-and-response-time/ Javid Jamae's thoughts on Java, software, and other random things Sat, 04 Jul 2009 08:31:57 +0000 http://wordpress.org/?v=2.7 hourly 1 By: paul http://javidjamae.com/2005/06/20/calculating-throughput-and-response-time/comment-page-1/#comment-314 paul Wed, 13 May 2009 09:52:50 +0000 http://javidjamae.com/?p=112#comment-314 Im trying to figure out something similiar to this, basically im looking to start counting in the urlrewriting and end at the end of the page rendering. I have a component that sends a UDP packet out in the render method at the end of the body loading,but i need to link in the load time for that request to the start of the url rewriting request. The main problem i can see is any redirects that happen, and being able to break down any blocking operations such as DB access within it. Im trying to figure out something similiar to this, basically im looking to start counting in the urlrewriting and end at the end of the page rendering. I have a component that sends a UDP packet out in the render method at the end of the body loading,but i need to link in the load time for that request to the start of the url rewriting request. The main problem i can see is any redirects that happen, and being able to break down any blocking operations such as DB access within it.

]]> By: Random Thoughts on Software » Blog Archive » Graphing Throughput http://javidjamae.com/2005/06/20/calculating-throughput-and-response-time/comment-page-1/#comment-301 Random Thoughts on Software » Blog Archive » Graphing Throughput Thu, 02 Apr 2009 03:12:20 +0000 http://javidjamae.com/?p=112#comment-301 [...] my post on calculating throughput and response time I discussed how to measure the average throughput and response time for a given amount of time. I [...] [...] my post on calculating throughput and response time I discussed how to measure the average throughput and response time for a given amount of time. I [...]

]]> By: Javid Jamae http://javidjamae.com/2005/06/20/calculating-throughput-and-response-time/comment-page-1/#comment-16 Javid Jamae Wed, 15 Feb 2006 17:14:00 +0000 http://javidjamae.com/?p=112#comment-16 Good point! I need to update my analogy to cover multiple CPUs and non-blocking IO. Thanks for the feedback. I'll try to get to this soon. Good point! I need to update my analogy to cover multiple CPUs and non-blocking IO. Thanks for the feedback. I’ll try to get to this soon.

]]> By: naasking http://javidjamae.com/2005/06/20/calculating-throughput-and-response-time/comment-page-1/#comment-15 naasking Tue, 14 Feb 2006 22:48:00 +0000 http://javidjamae.com/?p=112#comment-15 Just came across this, and thought I'd add:<br/><br/><i>With a single lane, our response time for this same load was 11 minutes / checkout, but with multiple lanes, our response time is 2 minutes / checkout, the best that our system can provide. Increasing the number of lanes (or threads) increased our throughput and allowed us to maintain optimum response time.</i><br/><br/>In general, this is definitely NOT true. In this analogy, the number of employees you have is equivalent to the number of CPUs on your machine. Opening more lanes (like 11) can thus only INCREASE response time and decrease throughput since the cashier now has to run between lanes to service them all. Optimal response time is achieved by opening as many lanes as you have employees.<br/><br/>You essentially say this in the last paragraph, but the way you portray it is backwards: you don't start with x lanes and try to satisfy with by hiring as many employees; instead, you have y CPUs and your architecture should only run y concurrent threads for optimal ultilization.<br/><br/>This is predicated on the assumption that the cashier is always actually doing real work while servicing a customer. If she's not, then you require a fully non-blocking asynchronous architecture to maintain optimal utilization (best), or you increase the number of threads (worse). Just came across this, and thought I’d add:

With a single lane, our response time for this same load was 11 minutes / checkout, but with multiple lanes, our response time is 2 minutes / checkout, the best that our system can provide. Increasing the number of lanes (or threads) increased our throughput and allowed us to maintain optimum response time.

In general, this is definitely NOT true. In this analogy, the number of employees you have is equivalent to the number of CPUs on your machine. Opening more lanes (like 11) can thus only INCREASE response time and decrease throughput since the cashier now has to run between lanes to service them all. Optimal response time is achieved by opening as many lanes as you have employees.

You essentially say this in the last paragraph, but the way you portray it is backwards: you don’t start with x lanes and try to satisfy with by hiring as many employees; instead, you have y CPUs and your architecture should only run y concurrent threads for optimal ultilization.

This is predicated on the assumption that the cashier is always actually doing real work while servicing a customer. If she’s not, then you require a fully non-blocking asynchronous architecture to maintain optimal utilization (best), or you increase the number of threads (worse).

]]>