-
Notifications
You must be signed in to change notification settings - Fork 773
feature: limit the number which download from supernode for one task #819
Conversation
b3b0e6e
to
17196e8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- the time to decrease the load. we should consider that when to decrease it if supernode doesn't receive the message from peers that downloading piece from supernode.
- the time to clean the load of supernode in progress manager
17196e8
to
987d1c0
Compare
f947b6e
to
b6ab252
Compare
b6ab252
to
7f73758
Compare
a13ee3b
to
86aa7a8
Compare
Codecov Report
@@ Coverage Diff @@
## master #819 +/- ##
==========================================
- Coverage 39.67% 39.44% -0.23%
==========================================
Files 109 110 +1
Lines 6415 6464 +49
==========================================
+ Hits 2545 2550 +5
- Misses 3661 3704 +43
- Partials 209 210 +1
Continue to review full report at Codecov.
|
pm.superLoad.add(taskID, newSuperLoadState()) | ||
} | ||
|
||
if loadState.loadValue.Add(delta) > limit && limit > 0 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The loadState
maybe nil
. It's not the object we created above when it's not exist before. We should get it again from map after adding. Otherwise we may use different objects with same taskId
in multi-goroutines. It's better to make the get
and add
as one atomic operation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
349b528
to
1d80d21
Compare
// when a peer success to download a piece from supernode, | ||
// and the load of supernode for the taskID should be decremented by one. | ||
if tm.cfg.IsSuperPID(pieceUpdateRequest.DstPID) { | ||
_, err := tm.progressMgr.UpdateSuperLoad(ctx, taskID, -1, -1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The load of supernode would not be decreased here because that the limit
is less than zero and the if
statement below would not execute the code loadState.loadValue.Add(delta)
.
if limit > 0 && loadState.loadValue.Add(delta) > limit {
loadState.loadValue.Add(-delta)
return false, nil
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for pointing that. And I have updated it. PTAL again. THX>
Signed-off-by: Starnop <[email protected]>
1d80d21
to
718f2fc
Compare
LGTM |
feature: limit the number which download from supernode for one task
feature: limit the number which download from supernode for one task
* feat: support list plugin Signed-off-by: Jim Ma <[email protected]> * chore: optmize plugin output Signed-off-by: Jim Ma <[email protected]>
Signed-off-by: Starnop [email protected]
Ⅰ. Describe what this PR did
When dragonfly begin to distribute a new file, a large number of download requests will be dispatched to the supernode node because there are no nodes in the current P2P network owns the file. Then the load of supernode will become heavier and heavier. According to the test, sometimes one peer will cost almost 2 minutes to download a piece which is only 4M from supernode(NOTE: the network bandwidth is enough). In order to avoid this, we should add a limit which only allows a limited number of downloads from supernode for one task at the same time. And then the others will download the piece form the peers which have downloaded from the supernode.
This will greatly reduce the load of the supernode.
Ⅱ. Does this pull request fix one issue?
None.
Ⅲ. Why don't you add test cases (unit test/integration test)? (你真的觉得不需要加测试吗?)
None.
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews