github/kubernetes
1
0
Fork 0
mirror of https://github.com/k3s-io/kubernetes.git synced 2025-07-23 03:41:45 +00:00
Code Issues Projects Releases Wiki Activity

Update docs and fix redundant logic of scheduler perf

Browse Source
This commit is contained in:
Wei Huang 2020-11-06 15:49:45 -08:00
parent 48a2bca893
commit 267acdbe81
No known key found for this signature in database
GPG Key ID: BE5E9752F8B6E005
2 changed files with 10 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
test/integration/scheduler_perf/README.md
View File

@ -68,9 +68,9 @@ To produce a cpu profile:
make test-integration WHAT=./test/integration/scheduler_perf KUBE_TIMEOUT="-timeout=3600s" KUBE_TEST_VMODULE="''" KUBE_TEST_ARGS="-alsologtostderr=false -logtostderr=false -run=^$$ -benchtime=1ns -bench=BenchmarkPerfScheduling -cpuprofile ~/cpu-profile.out"
```
### How to configure bechmark tests
### How to configure benchmark tests
Configuration file located under config/performance-config.yaml contains a list of templates.
Configuration file located under `config/performance-config.yaml` contains a list of templates.
Each template allows to set:
- node manifest
- manifests for initial and testing pod
@ -78,19 +78,13 @@ Each template allows to set:
- templates for PVs and PVCs
- feature gates
See `simpleTestCases` data type implementation for available configuration for each template.
See `op` data type implementation in [scheduler_perf_test.go](scheduler_perf_test.go)
for available operations to build `WorkloadTemplate`.
Initial pods create a state of a cluster before the scheduler performance measurement can begin.
Testing pods are then subject to performance measurement.
The configuration file under config/performance-config.yaml contains a default list of templates to cover
The configuration file under `config/performance-config.yaml` contains a default list of templates to cover
various scenarios. In case you want to add your own, you can extend the list with new templates.
It's also possible to extend `simpleTestCases` data type, respectively its underlying data types
It's also possible to extend `op` data type, respectively its underlying data types
to extend configuration of possible test cases.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/test/component/scheduler/perf/README.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/test/integration/scheduler_perf/README.md?pixel)]()

8
test/integration/scheduler_perf/scheduler_perf_test.go
View File

@ -173,8 +173,8 @@ func (cno *createNodesOp) isValid(allowParameterization bool) error {
if cno.Opcode != createNodesOpcode {
return fmt.Errorf("invalid opcode")
}
ok := (cno.Count > 0 ||
(cno.CountParam != "" && allowParameterization && isValidParameterizable(cno.CountParam)))
ok := cno.Count > 0 ||
(cno.CountParam != "" && allowParameterization && isValidParameterizable(cno.CountParam))
if !ok {
return fmt.Errorf("invalid Count=%d / CountParam=%q", cno.Count, cno.CountParam)
}
@ -226,8 +226,8 @@ func (cpo *createPodsOp) isValid(allowParameterization bool) error {
if cpo.Opcode != createPodsOpcode {
return fmt.Errorf("invalid opcode")
}
ok := (cpo.Count > 0 ||
(cpo.CountParam != "" && allowParameterization && isValidParameterizable(cpo.CountParam)))
ok := cpo.Count > 0 ||
(cpo.CountParam != "" && allowParameterization && isValidParameterizable(cpo.CountParam))
if !ok {
return fmt.Errorf("invalid Count=%d / CountParam=%q", cpo.Count, cpo.CountParam)
}