Speed up doc tests using RamDirectory #51418
Conversation
|
How does this explain the slowness when we run the build on a Do we know what specific recent changes are associated with the additional setup work you mention here? |
|
See the benchmarking results above. This provides a smaller speed-up on RamDisk (as This is an optional extension to #51430 |
|
I personally don't even like the fact that we are using ramdisks in CI. Users of ES do not generally run this way. It's simply a hack to squeeze more IO performance out of our build machines, but at the cost of an accurate testing environment. In reality, My preference would be for us not to introduce yet another hack which increases the delta between our test environment and a real production one just to squeeze more performance out of the build. The changes in #51430 already buys us a lot. The addition of this on top of that is much less dramatic and in a highly parallelized build the benefit would probably disappear entirely. |
| @@ -219,6 +222,9 @@ public static void deleteAll(Path[] dataPaths) throws IOException { | |||
|
|
|||
| // exposed for tests | |||
| Directory createDirectory(Path path) throws IOException { | |||
| if (USE_RAM_DIR) { | |||
| return new RAMDirectory(); | |||
There was a problem hiding this comment.
Can you use the new ByteBuffersDirectory which is the replacement for the deprecated RAMDirectory ?
|
I'm fine omitting this hack if we deem #51430 good enough. |
Speeds up docs / x-pack rest tests by using a RamDirectory for writing out cluster state updates. These tests spin up a single node and do not require the state to be persisted.
Benchmarking on my CI machine for
docs:checkshowed:RAMDisk
master: 16:09 minutes
ram-dir-metadata: 14:49 minutes
SSD
master: 32:20 minutes
ram-dir-metadata: 16:32 minutes
Relates #49753