feat: add Quickperf for simple performance testing with JDBC

[srozsnyai]

Adding JDBC quickperf tool for simple performance testing Spanner schemas

[conventional-commit-lint-gcf]

🤖 I detect that the PR title and the commit message differ and there's only one commit. To use the PR title for the commit history, you can use Github's automerge feature with squashing, or use automerge label. Good luck human!

-- conventional-commit-lint bot
https://conventionalcommits.org/

[olavloite]

nit: indent

[srozsnyai]

fixed

[olavloite]

nit: update to the latest version (26.38.0)

[srozsnyai]

updated and moved to dependencyManagement

[olavloite]

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

[srozsnyai]

moved to test dependency group

[olavloite]

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

[srozsnyai]

removed - its already in the dependencyManagement

[olavloite]

nit: remove superfluous comment

[srozsnyai]

removed

[olavloite]

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.

[olavloite]

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();
  }
}

[srozsnyai]

fixed

[olavloite]

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.

[olavloite]

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

[srozsnyai]

fixed

[olavloite]

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.

[olavloite]

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).