Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>In many server applications (might not be your case) performance problem manifest only under concurrent access and under load. Measuring absolute time a routine executes and trying to improve it is therefore not very helpful. There are problems with this method even in single-threaded applications. Measuring absolute routine time relies on the clock the platform is providing, and these are <a href="http://www.devx.com/Java/Article/28685" rel="nofollow noreferrer">not always very precise</a>; you better rely on average time a routine takes.</p> <p>My advice is:</p> <ul> <li>Use profiling to identify routines that execute the most times and take most time. </li> <li>Use tool like <a href="http://jakarta.apache.org/jmeter/" rel="nofollow noreferrer">JMeter</a> or <a href="http://grinder.sourceforge.net/" rel="nofollow noreferrer">Grinder</a> to elaborate representative test cases, simulate concurrent access, put your application under stress and measure (more importantly) throughput and average response time. This will give you a better idea of how your application is behaving as seen from the outside perspective.</li> </ul> <p>While you could use unit tests to establish some non functional aspects of your application, I think that the approach given above will give better results during optimization process. When placing time-related assertions in your unit tests you will have to choose some very approximative values: time can vary depending on the environment you are using to run your unit tests. You don't want tests to fail only because some of your colleagues are using inferior hardware. </p> <p>Tuning is all about finding right things to tune. You already have a functioning code, so placing performance related assertions <em>a posteriori</em> and without establishing critical sections of code might lead you to waste a lot of time on optimizing non-essential pieces of your application.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload