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

TraP slowdown when image store is enabled #538

Open
gijzelaerr opened this issue Oct 11, 2016 · 3 comments
Open

TraP slowdown when image store is enabled #538

gijzelaerr opened this issue Oct 11, 2016 · 3 comments

Comments

@gijzelaerr
Copy link
Collaborator

gijzelaerr commented Oct 11, 2016

Alexander his team indicated that TraP 4.0rc1 becomes quite slow when image store is enabled. When disabled TraP is super fast. This is because the images are stored in the database in serial (that is how SQL works) and not in parallel anymore (MongoDB was filesystem based). So question now is, is the slowdown too much or not. @AntoniaR indicated she doesn't need the image store, so for her this shouldn't be a problem.

If the slowdown is too much, we have various options:

  • Come up with a new workflow where we don't copy the images to a database, but somehow still make it possible banana can access the images that have been processed. In theory this is possible, it is just more of a business logic problem, banana needs to run on the same system as where the images are or needs to have access to the images in a similar way.
  • Switch back to the old method, store everything in MongoDB. I think this is a bad idea, since we have no proper way of managing the images. Last time vlo was full @Error323 just threw away all the data since there was no easy way to determine which images belong to which dataset.
  • Switch to a hybrid method where we store a more complex key in MongoDB so we can determine to which dataset / database an image belongs.

I prefer to leave it just the way it is, since it makes it much easier to manage the data and it requires less services so simplifies TraP.

@gijzelaerr gijzelaerr added the bug label Oct 11, 2016
@gijzelaerr gijzelaerr added this to the 4.0 milestone Oct 11, 2016
@AntoniaR
Copy link
Contributor

Clarification, I said that I stored images in other ways. Some kind of intelligent image store will be needed for multiple datasets, not just AARTFAAC, and I had basically proposed your first option when we discussed this - i.e. an image store separate to TraP but that Banana accesses.

So I think working round it for now is ok but we will need to quantify the slowdown and work round it better in the longer term.

@gijzelaerr
Copy link
Collaborator Author

point one is a logistics issue, not a software issue. I think how that turns out the AARTFAAC team has to decide when things get more a final form. I propose we just leave it for now as is, storing images this way is for debugging or experimenting.

@gijzelaerr gijzelaerr modified the milestones: Medium-term, 4.0 Oct 11, 2016
@AntoniaR
Copy link
Contributor

Image storage is not scalable for the long term use of the TraP. This option should be completely removed for R7.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants