You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The performance investigation of the tests in source-postgres revealed that java connector containers could require the better part of a second to do something as basic as respond to a spec API call. See #31298 (comment)
Part of what causes the latency to be high is that the JVM default settings are tuned for long-running operation. This is fine for us in a production setting but in tests these JVMs are typically short-lived. I've found that making the JIT less aggressive with -XX:TieredStopAtLevel=1 would speed things up noticeably. Perhaps there's other flags and settings worth using, I don't know yet.
Furthermore another cause of startup latency involves the logger. I don't think tests care much about the logs and overriding the log4j configuration with something like -Dlog4j.configurationFile=<some nonexistent path> would speed things up as well. Alternatively, we can add a very simple but valid log4j-for-integration-testing.propertiesresource file in the CDK somewhere and refer to it with-Dlog4j.configuration=`.
The text was updated successfully, but these errors were encountered:
Topic
No response
Relevant information
The performance investigation of the tests in source-postgres revealed that java connector containers could require the better part of a second to do something as basic as respond to a
spec
API call. See #31298 (comment)Part of what causes the latency to be high is that the JVM default settings are tuned for long-running operation. This is fine for us in a production setting but in tests these JVMs are typically short-lived. I've found that making the JIT less aggressive with
-XX:TieredStopAtLevel=1
would speed things up noticeably. Perhaps there's other flags and settings worth using, I don't know yet.Furthermore another cause of startup latency involves the logger. I don't think tests care much about the logs and overriding the log4j configuration with something like
-Dlog4j.configurationFile=<some nonexistent path>
would speed things up as well. Alternatively, we can add a very simple but validlog4j-for-integration-testing
.propertiesresource file in the CDK somewhere and refer to it with
-Dlog4j.configuration=`.The text was updated successfully, but these errors were encountered: