Very bad performance when deleting files from mediafire backend

Bug #1919020 reported by Jose Riha
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Duplicity
Triaged
Medium
Unassigned

Bug Description

Under certain conditions the performance of removing old backups from mediafire backend can be extremely bad - it can take hours to process such request.

The main contributor to this slowdown is a combination of
 - using mediafire in multibackend and the fact that file lists are not cached per store
   +
 - multiple calls to list mediafire folder contents
   (e. g. in multibackend.py's _delete function or mediafire backend's delete_file function which is still using API 1.3 for deletion. Unlike the latest version version 1.3 does not allow to delete the file by specifying full path and for each request the whole folder contents must be retrieved)
   +
 - large amount of files (e. g. 4 000+) in MF directory

duplicity 0.8.18
python 3.9.2
Arch Linux, x86_64

Revision history for this message
Jose Riha (jose1711) wrote :

I have made a new branch of what-seems-to-be-unmaintained mediafire sdk for python at https://github.com/jose1711/mediafire-python-open-sdk/tree/performance. The main feature is adding 1.4/1.5 API-specific arguments to functions which may greatly reduce time needed to e. g. delete the file from the service. It would be great if someone more experienced reviews that but the code did pass my tests.

To benefit from the changes mediafirebackend.py would need to be modified, e. g.:

def _delete(self, filename):
    u"""Delete single file"""
    uri = self._build_uri(filename)
    self.client.delete_file(uri)

would turn into

def _delete(self, filename):
    u"""Delete single file"""
    self.client.delete_file(filename)

etc.

Revision history for this message
Kenneth Loafman (kenneth-loafman) wrote :

Please submit a merge request to the mediafire project, then duplicity can be modified to match, otherwise we cause a lot of trouble for other users.

Changed in duplicity:
status: New → Triaged
Revision history for this message
Kenneth Loafman (kenneth-loafman) wrote : Update bug #1919020, status triaged, importance medium

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

 status triaged
 importance medium
 done
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEExwf+p6/3mDvUSsaGH1G0ZBEHM/EFAmBmE1EACgkQH1G0ZBEH
M/EzHwf/YieWhp8p0RjXcPcV2TbhJe6hsnwfogGqTbkYf46HW6sj/rcJZSNP9uwK
YbGObKo3pZ2tFrpq5JVnBgYiTf2ZjYjzXYJRFpRU8yTgQQIpYT8NEZEJSo7NWrHJ
RLtQJcpgm1EpkmyeC4616KCv+nV8Wj3m1UII0GdF+DV1eDyvTV0KD7TPJvxWiMxq
9u6Gr0iSOoemCjoE9m7rBErB7SoQX7d/70YtxzGOmEoOTeDSSx9XvvQ8uG/tuHXq
pgG9UOXYCs/4ZXyMaM0uNBXDbN0jzZJO1RqV1WeT4H/dasZcnPxNXbwEaEe6AjrY
5977QLHZsqWFW3kp2RO/bng9zZa/xA==
=BIt7
-----END PGP SIGNATURE-----

Changed in duplicity:
importance: Undecided → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.