improve the spawn feature #181
Conversation
1. boomer receive the spawn message from locust, then calculate the concurrency difference among current step and previous step, then increase reqeust goroutines or decrease request goroutines which is depended on the sign of difference value 2. adjust the unit test with new spawn codes
self test planthe self-test contains unit test and feature test based on the new codes, for the feature test, testing cases are as follows: self test resultunit test
feature testmain process test
add new boomer instance test
quit one boomer instance test
load shape test
|
| @@ -121,7 +121,10 @@ func (r *runner) outputOnStop() { | |||
| } | |||
|
|
|||
| func (r *runner) spawnWorkers(spawnCount int, quit chan bool, spawnCompleteFunc func()) { | |||
| log.Println("Spawning", spawnCount, "clients immediately") | |||
| for i := 0; i > spawnCount; i-- { | |||
There was a problem hiding this comment.
What about a new stopWorkers function?
There was a problem hiding this comment.
What about a new stopWorkers function?
OK, so u think it might be a better way to define another function such as stopWorkers which could handle spawnCount < 0
| // those goroutines will exit when r.safeRun returns | ||
| numClients := int(atomic.LoadInt32(&r.numClients)) | ||
| for i := 0; i < numClients; i++ { | ||
| r.stopChan <- true |
There was a problem hiding this comment.
Should we use a buffered channel? So message processing won't block here and wait for task execution.
There was a problem hiding this comment.
Should we use a buffered channel? So message processing won't block here and wait for task execution.
so u might think the channel should be buffered if we send true signal in for loop avoiding blocking the message processing? so for this way, the channel capacity need to be initialized for each spawn, is that right~
There was a problem hiding this comment.
Should we use a buffered channel? So message processing won't block here and wait for task execution.
so u might think the channel should be buffered if we send true signal in for loop avoiding blocking the message processing? so for this way, the channel capacity need to be initialized for each spawn, is that right~
i found it is not safe to resize the channel capacity for each spawn step, especially when the spawn count is decreasing comparing with previous spawn step. For instance, if spawn count is 30 of the previous step and then spawn count of current step is 20, if stopChan is resized for the current spawn period, then 10 of the goroutines could not exit normally.
therefore, I found another plan: try to make the stopChan as "unbounded channel": https://github.com/smallnest/chanx/blob/main/unbounded_chan.go then we could just focus on handling the signal sending to channel, the channel is buffered and also safe as i tested. in addition, i think the version 1.0.0 is enough for boomer to use.
however, it would change the type of stopchan and also influence some unit test cases
There was a problem hiding this comment.
I think a bounded channel is enough and you don't need to resize it.
See aslo
https://github.com/myzhan/boomer/blob/master/stats.go#L42
| r.numClients = 0 | ||
| // prevent receiving spawn message from master when boomer is handling stopping, | ||
| // that might happen when the numClients is too large and might take a while for stopping all request goroutines | ||
| for { |
There was a problem hiding this comment.
We don't need this loop if we use a buffered channel?
Proposed changes
improve the spawn feature
Types of changes
What types of changes does your code introduce to boomer?
Put an x in the boxes that apply
Checklist