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

Added object cache for Swift ext storage #7897

Merged
merged 1 commit into from
May 24, 2016
Merged

Added object cache for Swift ext storage #7897

merged 1 commit into from
May 24, 2016

Conversation

PVince81
Copy link
Contributor

This avoid calling the remote API for repeated calls to is_dir,
filetype, etc

I haven't fully tested this yet, but it does seem to be a bit faster.

I'm starting to think we might want to provide a generic cache for remote storages, because the Amazon implementation would also need it. The Dropbox one also has something similar.

@icewind1991

@karlitschek
Copy link
Contributor

looks good but not tested 👍

* @param string $path
* @return \OpenCloud\OpenStack\ObjectStorage\Resource\DataObject
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this return the fetched object or a bool?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If the object exists, it returns it.
If the object does not exist, it returns false, which is also cached. The point being that we don't want to check X times whether a file doesn't exist when we already knew it doesn't. (check is_dir/filetype, that one is nasty)

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'll add the bool in the doc

@leonardofln
Copy link

This improvement was excellent, greatly reduced the cURL requests and response time of the application. Good job!

@PVince81
Copy link
Contributor Author

I've updated it. For some parts, objects need to be removed from the cache to force refetch/repopulate.

Please review/test.

@PVince81
Copy link
Contributor Author

The branch should be ready now (rebased/squased). I've done some testing and fixed the remaining issue with caching.

@PVince81
Copy link
Contributor Author

Rebased.
I've tested most file operations including sync client, all should work correctly.

Please review @icewind1991 @schiesbn

@icewind1991
Copy link
Contributor

Changes look good 👍

@DeepDiver1975
Copy link
Member

testing ....

@DeepDiver1975
Copy link
Member

@PVince81 testStat failed:

PHPUnit_Framework_ExpectationFailedException : Failed asserting that 100 matches expected 1396009775.0.
Expected :1396009775
Actual   :100

@DeepDiver1975
Copy link
Member

debugging ....

@DeepDiver1975
Copy link
Member

the touch operation succeeds, but when retrieving the mtime the value is not as expected

@PVince81
Copy link
Contributor Author

Ok, I'll look into this.

@PVince81
Copy link
Contributor Author

I'll also check master, because the touch operation was fixed in a separate PR.

@PVince81
Copy link
Contributor Author

@DeepDiver1975 I ran the unit tests and I'm getting something different on this branch:

1) Test\Files\Storage\Swift::testStat
Failed asserting that false is true.

/srv/www/htdocs/owncloud/tests/lib/files/storage/storage.php:213

2) Test\Files\Storage\Swift::testUnlink
Failed asserting that true is false.

/srv/www/htdocs/owncloud/tests/lib/files/storage/storage.php:245

Not sure if it's due to connection speed being different from yours.
I'll try and find out what's going on.

@PVince81
Copy link
Contributor Author

@DeepDiver1975 I have the feeling that OpenStack doesn't automatically update the mtime of its root. Also even stranger it always returns the same timestamp, even when I delete the bucket and re-create it. It seems to be the bucket's creation time, seen this with a newly created bucket.

Do you get the same results on master ? If yes I suggest to merge this first and I'll have a look at that issue separately (with potential backport). Maybe we need to "touch" the root as well (this adds our custom mtime attribute) to manually propagate the change.

@PVince81
Copy link
Contributor Author

I also realized that mtime won't propagate to parent folders either since OpenStack is a flat object hierarchy. To fix this we'd need to touch (update the mtime) every parent folder up to the root...
I'll investigate this separately.

@DeepDiver1975
Copy link
Member

@PVince81 I'll test this and master tomorrow - I've been asking myself if we should put each external fs into it's own repo and prepare travis to execute the tests on - as far as possible - locally installer services (e.g. Ceph as S3 backend etc)

@PVince81
Copy link
Contributor Author

PVince81 commented Apr 1, 2014

Thanks. I'd like to get this merged first, then possibly look into making the mtime propagation and update detection work.

What do you mean with own repo ? Having each external storage as separate GitHub repo app ?

@DeepDiver1975
Copy link
Member

Having each external storage as separate GitHub repo app ?

Yes - divide and conquer!

@PVince81
Copy link
Contributor Author

PVince81 commented Apr 1, 2014

That would be quite a lot of backends. Might make sense for some of them, or at least the "exotic" ones like object store. The FTP, SFTP ones could stay here. Or group them somehow.

Changes will be needed in the app to make it possible for external apps to register their backends, which makes sense as this is currently not supported and makes it impossible for 3rd party to provide their own ext storages.

@@ -53,6 +53,12 @@ class Swift extends \OC\Files\Storage\Common {
private static $tmpFiles = array();

/**
* Object cache, map of path to object
Copy link

Choose a reason for hiding this comment

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

@PVince81 PVince81 removed this from the 8.2-current milestone Sep 21, 2015
@RobinMcCorkell
Copy link
Member

It seems that Flysystem performs no caching at all... but if we were to have a single storage API provided by Flysystem, implementing generic caching would be a possibility

@DeepDiver1975
Copy link
Member

It seems that Flysystem performs no caching at all...

aha .... http://flysystem.thephpleague.com/caching/

@RobinMcCorkell
Copy link
Member

@DeepDiver1975 Or that 🙈

@PVince81
Copy link
Contributor Author

Rebased.

Has failing tests:

2) Test\Files\Storage\Swift::testRenameDirectory
Failed asserting that false is true.

/var/www/html/owncloud/tests/lib/files/storage/storage.php:468

3) Test\Files\Storage\Swift::testCopyDirectory
Failed asserting that false is true.

/var/www/html/owncloud/tests/lib/files/storage/storage.php:522

@PVince81
Copy link
Contributor Author

Rebased and fixed unit tests.
Also now using the CappedCache for the stat cache.

Please review @owncloud/filesystem
@owncloud/qa can you help regression test this ? All file operations should still work, this makes SWIFT external storage much faster.

@PVince81
Copy link
Contributor Author

also @tjdett @MorrisJobke in case you are interested

@icewind1991
Copy link
Contributor

👍

This avoid calling the remote API for repeated calls to is_dir,
filetype, etc
@PVince81 PVince81 force-pushed the ext-swiftcaching branch from 39046a8 to f77a11a Compare May 24, 2016 11:30
@PVince81
Copy link
Contributor Author

Rebased due to the PSR-4 changes. (no conflicts, automatically resolved)

@PVince81
Copy link
Contributor Author

Ran the Swift tests locally and they passed, merging.

@PVince81 PVince81 merged commit e8c3794 into master May 24, 2016
@PVince81 PVince81 deleted the ext-swiftcaching branch May 24, 2016 14:21
@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 this pull request may close these issues.

10 participants