-
Notifications
You must be signed in to change notification settings - Fork 3
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
Ahoy containers #15
Ahoy containers #15
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I commented on some suggestions about the names of the services.
About the volumes, I made some suggestions so that we can at that first moment, persist the data somewhere.
In the case of high memory usage, correct me if I'm wrong, is this related in any way to all the dev
dependencies that are installed?
About the proper logging and poetry dependency management, I need to do a study and see the best practices
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have much knowledge about using Docker (I definitely need some remembering and new studies on it), with that said I think I can't really give a appropriated opinion, but this seems good to me.
About the memory footprint, do you have some refs our thoughts on what level of memory use we should have? I think a good approach to investigate this would be to strip the project removing everything and running only with starlette, and again only with starlette and ariadne, in a way that we can learn what is the minimum consumption we can achieve with our current choices.
Thanks! Those were included.
No way to tell without investigating. Created #16 to track that.
Gonna leave logging for future improvements as they aren't critical. As for
Alright! I'm merging then.
It varies proportionately to how many dependencies there are. I remember reading that vanilla django footprint was ~20MB. However, I did a search and couldn't find proper references and benchmarks. It's something worth doing to in #16. |
This PR (partly) resolves #8.
What this adds
Mainly, it implements a few things:
docker-compose
.Memory footprint
Using debian's busters distro, a few checks that might be useful when we're benchmarking this app.
Which is pretty straightforward, ~44MiB per worker of memory footprint. IMO it's definitely something work investigating i.e. what is taking so much space since this is supposed to be a lean framework.
What is currently missing
For this PR, it is missing a few things that are being added as work is progressed:
What needs to be done
This work enables the service to be fully usable in local and development environments. So what is "missing" from this work in order to be used in production environments:
But those concerns would be addressed after we went public, IMO. But are kept in record so we have a clear vision of next steps.
@rafamelos @andreyrcdias care to review & complement?