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.

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

Chunked Files: Optimize checking if all chunks are there #22601

Closed
guruz opened this issue Feb 23, 2016 · 7 comments · Fixed by #22602
Closed

Chunked Files: Optimize checking if all chunks are there #22601

guruz opened this issue Feb 23, 2016 · 7 comments · Fixed by #22602

Comments

@guruz
Copy link
Contributor

guruz commented Feb 23, 2016

(not proven 100%)

We've seen benchmarks (TODO: where) where we have seen that for chunked files the later chunks take longer and longer than the first chunks. We're thinking isComplete of OC_FileChunking is to be blamed because it checks the file system for the existance of all chunks for the file. This gets slower (? probably because a succesful stat takes more time)

public function isComplete() {

One optimization idea: Have a fast path to check for currentChunk+1 (if it has that many chunks) and if that does not exist then return immediatly as false instead of counting all chunks.

FYI @dragotin @DeepDiver1975 @jturcotte @ogoffart @rullzer

@ogoffart
Copy link

Client issue showing that the more chunk, the slower: owncloud/client#4354

rullzer added a commit that referenced this issue Feb 23, 2016
Fixes #22601

Before we did a full test on all chunks to verify if a chunked upload
was completed. This is unneeded since if we are missing one chunk we can
already fail.

Also we look from back to front since it is much more likely that we
find a missing chunk thus can error out early.
@PVince81 PVince81 added this to the 9.1-next milestone Feb 25, 2016
@PVince81
Copy link
Contributor

One optimization idea: Have a fast path to check for currentChunk+1 (if it has that many chunks) and if that does not exist then return immediatly as false instead of counting all chunks.

Sounds like a plan.

@rullzer
Copy link
Contributor

rullzer commented Feb 25, 2016

PR already in #22602

@rullzer
Copy link
Contributor

rullzer commented Feb 25, 2016

One optimization idea: Have a fast path to check for currentChunk+1 (if it has that many chunks) and if that does not exist then return immediatly as false instead of counting all chunks.

Sounds like a plan.

After thinking about it we now just traverse the list from back to front (instead of front to back) and error out the moment we find 1 missing chunk.. But the idea is the same :)

@rullzer
Copy link
Contributor

rullzer commented Feb 25, 2016

@PVince81 @cmonteroluque just FYI this helps with a blue ticket on the client.. so would 9.0.1 be an option? (PR is already available).

rullzer added a commit that referenced this issue Mar 2, 2016
Fixes #22601

Before we did a full test on all chunks to verify if a chunked upload
was completed. This is unneeded since if we are missing one chunk we can
already fail.

Also we look from back to front since it is much more likely that we
find a missing chunk thus can error out early.
@PVince81 PVince81 modified the milestones: 9.0.1-next-maintenance, 9.1-next Mar 2, 2016
@PVince81
Copy link
Contributor

PVince81 commented Mar 2, 2016

done

rullzer added a commit that referenced this issue Mar 7, 2016
Fixes #22601

Before we did a full test on all chunks to verify if a chunked upload
was completed. This is unneeded since if we are missing one chunk we can
already fail.

Also we look from back to front since it is much more likely that we
find a missing chunk thus can error out early.
rullzer added a commit that referenced this issue Mar 9, 2016
Fixes #22601

Before we did a full test on all chunks to verify if a chunked upload
was completed. This is unneeded since if we are missing one chunk we can
already fail.

Also we look from back to front since it is much more likely that we
find a missing chunk thus can error out early.
@MorrisJobke MorrisJobke modified the milestones: 9.1-current, 9.0.1-current-maintenance Mar 15, 2016
@lock
Copy link

lock bot commented Aug 5, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Aug 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants