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

Reuse Bucket and Botocore objects to prevent cyclic references #112

Merged
merged 2 commits into from
Apr 26, 2018

Conversation

kkopachev
Copy link
Collaborator

@kkopachev kkopachev commented Mar 13, 2018

calling Botocore on each call to loader/storage seems expensive, given that tornado_botocore object then creates client object, which has a bunch of cyclically referenced objects inside. About 1-2k of objects total. Eventually they are getting garbage collected, but why bother running expensive gc, when reusing same objects can improve things.

This PR essentially implementing ideas I outlined in #109. Collected garbage went down from 1600-1700 objects to 34 on each call to loader.

@Bladrak thoughts?

closes #109

@Bladrak
Copy link

Bladrak commented Mar 13, 2018

Hi, and thanks for contributing :)
I'm wondering whether this doesn't duplicate a bit the logic within the session handler. Having a global bucket may remove the need for a global session. What do you think?

@Bladrak
Copy link

Bladrak commented Mar 15, 2018

@kkopachev given I've merged the MAX_RETRY pull request, this one presents conflicts. I'd rather only publish one version with both fixes if that's ok with you?

@kkopachev
Copy link
Collaborator Author

@Bladrak that's totally fine with me releasing in one shot. I'll rebase this PR.

@kkopachev kkopachev force-pushed the less-cycles branch 2 times, most recently from c73bd00 to 55330eb Compare March 19, 2018 05:22
@kkopachev
Copy link
Collaborator Author

@Bladrak rebased on top of latest master, but discovered that thumbor for each request creates new storage/result storage instance, which ruins the whole idea 😞
We could make the Bucket objects for get/put/delete to be stored in global registry, but not sure how good idea is that. What do you think?

@Bladrak
Copy link

Bladrak commented Mar 19, 2018

I'm not familiar with the global registry, is this handled by tornado?
Given the storage/result storage instances are directly handled by thumbor, we may not be able to do much here... Besides maybe trying to provide a singleton for those?

@kkopachev
Copy link
Collaborator Author

sorry, being busy lately.
Yes, I meant something like Singleton, but we'll have multiple instances, one per bucket+operation. I hope I could make these fixes soon.

@kkopachev
Copy link
Collaborator Author

@Bladrak I think this is ready. CircleCI issue seems unrelated to code changes, but rather CI config itself. Tests are passing locally.

In short, Bucket object is now singleton (for a given set of arguments) and contains botocore clients on it, so it does not reinitialize everything on every request.

@Bladrak
Copy link

Bladrak commented Apr 25, 2018

LGTM, I'm trying to have the tests pass before merging. Do you have some metrics about the improvements of GC?

@Bladrak
Copy link

Bladrak commented Apr 25, 2018

@kkopachev could you rebase against master to use latest CI workflow? This should hopefully stabilize your PR :)

@kkopachev
Copy link
Collaborator Author

all green now!

@kkopachev
Copy link
Collaborator Author

FYI, I have a counterpart PR opened on botocore repo boto/botocore#1450 which supposed to fix circularly referenced objects creation on each request.

@Bladrak Bladrak merged commit 8909eda into thumbor-community:master Apr 26, 2018
@Bladrak
Copy link

Bladrak commented Apr 26, 2018

Great thanks! I'll try to publish a new version today

@kkopachev kkopachev deleted the less-cycles branch April 26, 2018 16:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Circular references when creating Botocore objects
2 participants