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
This work was spawned by reports of people encountering context deadline errors when trying to list scenarios. We previously had a hard timeout of 5 seconds for listing which we have changed to use scenario level `--timeout` flag going forward. This solved the immediate problem but begged the question of why scenario listing was taking nearly that long at all.
When I was investigating this I determined there were several reasons that listing was slow:
* We were always decoding and evaluating all scenarios when listing, even though we only needed the reference information. If you're using `enos scenario list` to validate that the configuration for all scenarios is correct, that makes sense, but most people are probably using it to see which scenarios are available and don't necessarily want to validate all of them every time the command is invoked.
* When filtering we would always fully decode all scenarios before filtering to keep the scenarios that are desired.
* Every time we were comparing a matrix vector we were making a copy of it. The problem compounded exponentially as we added additional vectors and elements to the matrix. Nearly 3/4's of the CPU time we spent when listing scenarios was actually being used here for allocations, garbage collection, and sorting after copy.
To improve our situation we do the following:
* Add support to the decoder for shallow decoding of scenarios to the reference level.
* Add filtering support to the decoder. Now we can optionally shallow decode, then filter, before fully decoding a scenario.
* Rewrite our matrix vector implementation. Instead of an array alias the matrix Vector type is a struct which we use for new efficiency gains. We now always pass references to Vectors instead of passing them by value and creating copies. We also lazily keep track of a sorted copy of vectors to allow faster repeat comparisons. This has drastically reduced our allocations and garbage collection.
When we combine all of these changes we improved the listing time by at least an order of magnitude. A drawback to this approach is that listing no longer validates that the full configuration in a flight plan, the scenarios and all of their variants. To handle that we introduce a new `validate` sub-command that fully decodes all matched scenarios to ensure that the flight plan is valid. We also introduce the `--profile` hidden flag that will turn on CPU and memory profiling and output the pprof files into the current directory. These profiles were useful in determining the bottleneck of the prior implementation so we'll leave them there for possible future use.
* Add support for reference level scenario decoding
* Add support for filtering during decoding
* Rewrite matrix vector implementation to reduce allocations and GC
* Use references to vectors instead of passing by value
* Lazily create ordered copies of vectors when comparing
* Add `--profile` hidden flag to enable CPU and memory profiling
* Add `validate` sub-command for validating configuration of a flight plan.
* Bump version
Signed-off-by: Ryan Cragun <[email protected]>
Copy file name to clipboardExpand all lines: internal/command/enos/cmd/scenario_check.go
-1Lines changed: 0 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,6 @@ import (
13
13
funcnewScenarioCheckCmd() *cobra.Command {
14
14
cmd:=&cobra.Command{
15
15
Use: "check [FILTER]",
16
-
Aliases: []string{"validate"}, // old name of the check command
17
16
Short: "Check that scenarios are valid",
18
17
Long: fmt.Sprintf("Check that scenarios are valid by generating the Scenario's Terraform Root Module, initializing it, validating it, and planning. %s", scenarioFilterDesc),
0 commit comments