Jan 8, 2016
There is an intentional delay in accepting connections for security purposes. We are using org.mindrot.BCrypt class to verify passwords, which purposely uses slow hashing to avoid brute force attack. We have some customers using PHP at high scale in a configuration that involves thousands of connections and shorter connection lifecycles, but that is unusual and even then there is significant reuse of connections.
From anecdotal data, the delay is around 150ms, so if you are seeing .5 seconds, it may that the JDBC Driver connects to each server serially when given a comma-separated list of nodes in the connection string.
Do you have some sort of use case that requires creating JDBC connections frequently, or could they be reused?
Note that unlike most general-purpose SQL databases where a JDBC connection is dedicated to a client thread for the life of a transaction, which often may be controlled from the client, all VoltDB transactions are controlled from within a stored procedure. Each request to the database involves a separate transaction (essentially AutoCommit mode). Therefore, even though the JDBC Connection API is synchronous, and calls to procedures or Statements will wait (block) the calling thread until the response is received, the Connection object itself is thread-safe and can be used simultaneously by multiple thread, even thousands of threads. Connection pooling is not necessary or recommended, and the Connection objects should be reused.
Jan 12, 2016
you are right, that's no "normal" use-case. I want to / or try to find out how long the authentication time takes.
With one server the connection time is 0.4510 sec and with more servers (for example 3) the connection time is 0.6630 sec. (with security enabled)
Interesting is, that when I make a new connection in the same java application the connection time is much less (it changes from 0,4510 to 0,001 sec). Is it possible that the jdbc driver takes so much time to load or does BCrypt only makes the hash the first time?