Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Limit concurrent HTTP requests when downloading binary dependencies #4017

Merged
merged 4 commits into from
Jan 14, 2022
Merged

Limit concurrent HTTP requests when downloading binary dependencies #4017

Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
2b9ebca
Limit concurrent download of binary dependencies
plu Jan 13, 2022
92a1588
Add retryStrategy for downloading binary dependencies
plu Jan 13, 2022
8d4b724
Limit concurrent requests to Concurrency.maxOperations
plu Jan 13, 2022
97ccc8d
Simplify DispatchGroup/DispatchSemaphore usage
plu Jan 13, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 9 additions & 1 deletion Sources/Workspace/Workspace.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2270,8 +2270,12 @@ extension Workspace {
}
}

// download max n files concurrently
let semaphore = DispatchSemaphore(value: 8)
plu marked this conversation as resolved.
Show resolved Hide resolved

// finally download zip files, if any
for artifact in (zipArtifacts.map{ $0 }) {
semaphore.wait()
Copy link
Contributor

@tomerd tomerd Jan 13, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

similar to how we handle group, we should should also defer a signal on the semaphore and then another wait after L2289, otherwise the continue from L2284 may create problems

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, maybe we should do group.enter() and semaphore.wait() only once after the guard, when we're sure we're actually executing the asynchronous HTTP request? Probably I'm just missing some detail about the lines before the guard though, not understanding the full picture why they also should be part of the DispatchGroup. What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just pushed 97ccc8d - which is what I meant with my earlier comment. If this is wrong for some reason that I don't see yet, please let me know and I'll revert it and make the change you suggested in your first comment.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes this seems like a good change!

group.enter()
defer { group.leave() }

Expand All @@ -2287,6 +2291,7 @@ extension Workspace {
headers.add(name: "Accept", value: "application/octet-stream")
var request = HTTPClient.Request.download(url: artifact.url, headers: headers, fileSystem: self.fileSystem, destination: archivePath)
request.options.authorizationProvider = self.authorizationProvider?.httpAuthorizationHeader(for:)
request.options.retryStrategy = .exponentialBackoff(maxAttempts: 3, baseDelay: .milliseconds(50))
request.options.validResponseCodes = [200]
self.httpClient.execute(
request,
Expand All @@ -2297,7 +2302,10 @@ extension Workspace {
totalBytesToDownload: totalBytesToDownload)
},
completion: { downloadResult in
defer { group.leave() }
defer {
group.leave()
semaphore.signal()
}

switch downloadResult {
case .success:
Expand Down