Hello Phil, I saw a few more commits this weekend on [performance] and thought you might welcome a bit of feedback:
Use System.nanoTime() instead of System.currentTimeMillis()? In LoadGenerator execute() ex.awaitTermination(...) may throw an InterruptedException, you may wish to catch that before calculating the summary statistics. If your intent is to start all of the client threads at the same time, I believe you want to use a pair of CountDownLatches instead of the thread pool executor. See e.g. Listing 5.11 in _Java Concurrency in Practice_ (Goetz et al., 2006). Executor.execute() only promises to "execute the given command at some time in the future." Perhaps more useful than having the client threads calculate time to wait between executions and perform timings would be an implementation of ExecutorService that does this instead. It might also start the client threads at the same time. Maybe a custom class that extends RunnableFuture could provide the setUp() and cleanUp() methods and return the execution time as the future (see CustomTask in javadoc for AbstractExecutorService)? What method(s) do you use to monitor the pool and/or the database when running these performance tests? You mention "instrumented dbcp and pool jars" and database server log files in the comments for DBCP-212. I have generated RRDTool-style connection graphs based on queries against Oracle's V$SESSION view; if similar data are available for other databases such might make a useful companion tool. Both JRobin [1] and RRD4J [2] are LGPL however. michael [1] http://sourceforge.net/projects/jrobin [2] http://rrd4j.dev.java.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
