nit: indent

fixed

nit: update to the latest version (26.38.0)

updated and moved to dependencyManagement

The convention is to list all compile time dependencies first, and then all test dependencies. So move this further down in the pom file.

moved to test dependency group

This should not be here. Importing a pom is something that you should only do in the dependencyManagement section above.

removed - its already in the dependencyManagement

nit: remove superfluous comment

removed

See my comment further above. You don't have to force the emulator to use port 9010, you can also let it run on a random port, and just add localhost:<port> to the connection URL. The autoConfigEmulator=true flag will still work as it does now, but will use the host/port in the connection URL instead of the default localhost:9010.

You can replace all of this (and also remove the entire createInstance method) by using the JDBC driver for doing this as well. The autoConfigEmulator=true flag will automatically create the instance and the database that you specify in the JDBC connection URL, so all you need to do is something like this:

try (Connection connection = DriverManager.getConnection("jdbc:cloudspanner:/projects/%s/instances/%s/databases/%s?autoConfigEmulator=true")) {
  try (Statement statement = connection.createStatement()) {
    for (String ddl : ddlList) {
      statement.addBatch(ddl);
    }
    statement.executeBatch();
  }
}

fixed

What I meant was that you can then also remove the -Dexec.mainClass="..." from the above command as well, making it a bit easier to run the application.

this does not appear to format correctly. See https://github.com/googleapis/java-spanner-jdbc/blob/60a355aec261f0174c19688058b22d1a71e19492/samples/quickperf/readme.md#end-to-end-example

fixed

That is true, but an InterruptedException means that the thread should stop executing. So this should either:

• Throw a RuntimeException to force an exit of the thread.
• Return a value that indicates to the caller that it should stop (so for example return a boolean true as in 'should stop', and then have an if block in the calling loop that checks what was returned, and if true, stops the loop.

Yes, I understand that. But what happens here is that:

1. The application runs the sampling query for QuickPerfRunner number 1. That takes let's say 2 seconds.
2. QuickPerfRunner number 1 is started and starts executing the benchmark.
3. Step 1 is then repeated for QuickPerfRunner number 2. This then also takes 2 seconds.
4. Etc.... Meaning that if you have 10 threads, it takes 20 seconds before the 10th thread starts. That again means that you can have a relatively significant delay between the time that the first thread starts and the last thread starts, which again can have an impact on the results that you see (you probably also get the same effect at the end of the test run, as the first thread is likely to finish well ahead of the last thread).