Task #10475 (closed)
Opened 11 years ago
Closed 9 years ago
Bug: webgateway deleteObjects() performance is poor
| Reported by: | aknab | Owned by: | mtbcarroll |
|---|---|---|---|
| Priority: | critical | Milestone: | 5.1.0-m4 |
| Component: | Services | Version: | 4.4.8 |
| Keywords: | n.a. | Cc: | java@… |
| Resources: | n.a. | Referenced By: | n.a. |
| References: | n.a. | Remaining Time: | n.a. |
| Sprint: | n.a. |
Description
When deleting OriginalFile? objects using the webgateway's deleteObjects method, performance is slow. Deleting 100 objects can take several seconds, which is a problem when a large number of objects (3000+) have to be removed.
https://github.com/knabar/openmicroscopy/commit/bc2edfc12ccd6429c9cf5b79da16a1f1a473307f
Branch: https://github.com/knabar/openmicroscopy/commits/delete-status-test
Change History (14)
comment:1 Changed 11 years ago by jmoore
- Milestone set to OMERO-4.5
- Priority changed from minor to critical
- Sprint set to Bugs Fixing
- Summary changed from webgateway deleteObjects() performance is poor to Bug: webgateway deleteObjects() performance is poor
- Type changed from Bug to Task
comment:2 Changed 11 years ago by jburel
- Sprint changed from Bugs Fixing to 2013-04-09 (7))
Moved from sprint Bugs Fixing
comment:3 Changed 11 years ago by jburel
- Sprint changed from 2013-04-09 (7)) to 2013-05-07 (8)
Moved from sprint 2013-04-09 (7))
comment:4 Changed 11 years ago by jburel
- Sprint changed from 2013-05-07 (8) to Blocker 4.4.9 (1)
Moved from sprint 2013-05-07 (8)
comment:5 Changed 11 years ago by jamoore
- Cc java@… added
- Component set to General
- Milestone changed from OMERO-4.4.9 to OMERO-5
- Sprint Blocker 4.4.9 (1) deleted
- Version set to 4.4.8
This is unlikely something that can be safely addressed in 4.4.x and particularly not 4.4.9. Pushing to OMERO-5 since there were a number of graph changes there with which we could perhaps introduce a general re-architecting.
comment:6 Changed 10 years ago by jamoore
- Milestone changed from 5.0.0 to 5.0.0-beta3
comment:7 Changed 10 years ago by jamoore
- Owner changed from jamoore to mtbcarroll
comment:8 Changed 10 years ago by mtbcarroll
This looks rather more like that problem with transactions in the repository DAO that Colin was talking about, than anything relating to graphs. (What's the ticket number for that one?) Do you want me to try to look into that one too then?
comment:9 Changed 10 years ago by mtbcarroll
Ah, it's #11084. (Took a while, Trac's search is rubbish.)
comment:10 Changed 10 years ago by jamoore
Let's definitely get the graph testing & bugs out of the way first, especially if you're relatively certain that this is due to follow-on transactions.
comment:11 Changed 10 years ago by mtbcarroll
Agreed: unfortunately for me, #11779 is is due for m3, so it will be out of the way first. (-: And, it would be nice if for 5.1.0 delete really could be markedly faster than in 5.0.6, through our dealing with these multiple issues.
comment:12 Changed 9 years ago by mtbcarroll
- Status changed from new to accepted
comment:13 Changed 9 years ago by mtbcarroll
- Component changed from General to Services
- Milestone changed from 5.1.0 to 5.1.0-m4
comment:14 Changed 9 years ago by mtbcarroll
- Resolution set to fixed
- Status changed from accepted to closed
A possible cause is that the many-small graphs case is almost completely untested in comparison to the few-large graphs case. Andreas is trying to create a test that reproduces. One option may be to try to batch multiple omero.cmd.Delete commands into a single Deletion object.