-
Hi, |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 10 replies
-
@lvazdela So .. first questions are:
The way you have described it, the application is swapping to disk - which will always make operations slower. |
Beta Was this translation helpful? Give feedback.
-
@lvazdela System SpecsData Size Locally
CalculationsApprox 100K items / 203 = ~500 API response bundles to process (this can be verified when using Execution Time for a --resync (v2.5.0)A
Execution Time without --resync (v2.5.0)
Execution Time for --single-directory (v2.5.0)
Now .. whilst 100K files and folders is not 113K files and folders ... an additional 13K is not going to add hours and/or days to how the client operates. I am curious as to the claim your making. |
Beta Was this translation helpful? Give feedback.
-
@lvazdela
So to be at least fair in any comparison:
Now ... I 100% expect the following:
So to validate this, then instead of using --single-directory "PROYECTOS DE R" , use a 'sync_list' file to only scan that particular folder. As the v2.5.2 client is now no longer performing an exhaustive scan of the online tree, there should a difference in how v2.5.2 is operating and how long the operations take. This being said - if 'PROYECTOS DE R' is a Shared Folder .. all bets are off - the exhaustive scan again will be used, because Lastly, you are using Ubuntu (your choice .... ) so you are using no doubt a broken curl version (got to love a distribution providing users with broken packages in the guise of stability .. again your choice). To work around these 'issues' add to a 'config' file the following options:
These are valid for v2.4.25 and v2.5.2 |
Beta Was this translation helpful? Give feedback.
@lvazdela
Your testing is 100% invalid for a number of reasons:
/delta
call, finds 0 changes, and immediatly goes to validation of items in the database--dry-run
which is forcing a DB upgrade, thus a 100% way more intensive scan--single-directory
to limit the sync scope. In v2.4.25 this still uses the/delta
call but without a checkpoint, thus, it goes back to 'point 1' .. no changes , nothing transferred (which is not correct - a v2.4.25 bug)