RFC: Cache locally the filecache information #31793
Conversation
This on one side might improve the performance by doing less requests to the database but more importantly this decrease the likeliness of read after write errors in a cluster setup since we don't requests the data from the database that might be outdated. Currently this only cache get/put/insert/update and for copy/move/propagator this clear the cache. Signed-off-by: Carl Schwan <carl@carlschwan.eu>
CarlSchwan
force-pushed
the
performance/local-cache-filecache
branch
from
6d38880
to
a8f72a9
Compare
|
Remaining issues are mostly with the unit tests of the sharing and versions apps that directly do queries to the filecache table :( |
CarlSchwan
changed the title
|
@skjnldsv @icewind1991 What do you think of this? |
| $values['fileid'] = $fileId; | ||
| $valuesDefault = [ | ||
| 'encrypted' => 0, | ||
| 'storage_mtime' => 0, | ||
| 'permissions' => 0, | ||
| 'etag' => null, | ||
| 'checksum' => null, | ||
| 'metadata_etag' => null, | ||
| 'creation_time' => null, | ||
| 'upload_time' => null, | ||
| ]; |
There was a problem hiding this comment.
This is the only part I don't like.
Hardcoded values? Do we have a single point of truth for what can be populated as file data? Is this not dynamic?
Any reason we only store those ones?
As a summary, could you give a little background on how you found that specific list? :)
There was a problem hiding this comment.
This is basically the default value coming from the database, I don't like that we duplicate it either
Currently, we basically create an entry in the DB with partial data, then the missing data is filled by the DB with the default value and then we fetch the object from the DB.
|
will you finish this ? please consult with @icewind1991 also |
|
Currently this will lead to state size information for folders if it's contents have been modified. In general I'm very hesitant to do this due to reasons like this, it might be fine with proper pessimistic cache invalidation |
|
As there is no feedback since a while I will close this ticket. |
This on one side might improve the performance by doing less requests to
the database but more importantly this decrease the likeliness of read
after write errors in a cluster setup since we don't requests the data
from the database that just got updated
Currently this only cache get/put/insert/update and for
copy/move/propagator this clear the cache.
Signed-off-by: Carl Schwan carl@carlschwan.eu