-
-
Notifications
You must be signed in to change notification settings - Fork 3k
refactor: better python performance #500
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
base: main
Are you sure you want to change the base?
refactor: better python performance #500
Conversation
| --- | ||
| appPort: 8080 | ||
| db: | ||
| user: fastapi_app |
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 did not run as a pod, instead I just ran against docker
|
Do you believe running Pypy would improve Python performance? Pypy + FastAPI = fastapi/fastapi#3944 |
|
Maybe @emerson-proenca; If you make a PR I'd love to run it. I've not had a lot of experience with it, so I consider it to be esoteric at the moment; but maybe it's very easy and I'm just unclear about approach. I do know AI was telling me I was barking up the wrong tree with this, but then when I looked at all my latencies, they seemed to support me, more than AI review of my work. |
|
Here are some logs from K6 test included with PR, run on an M2 Air laptop |
|
Apologies, I realised after re-running the base-line I'd committed something I should not have. I've commented it out, but basically, I doubled the number of queries being run as part of a failed experiment and then accidentally |
antonputra
left a comment
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.
Thank you, @Lewiscowles1986, for the PR. Sorry I don't have clear guidelines for pull requests. Would you be able to just create a fastapi-app-v2 folder and keep the original as is? It's just easier to compare in the future.
|
To be honest, it merging isnt' the most important thing as you'll only get at most a few thousand requests (not per second, overall 😄 ) Thank you for the tutorial; if you'd still like the changes I'll make them |
|
@Lewiscowles1986 Yes please, I'll keep it. When it's time to refresh the benchmark, I'll go over and test everything again. |
So I tried a few things, which get the minimum time in k6 down to microseconds for a request. They set slightly more aggressive timeouts, use pydantic to marshal the response from the POST endpoint to the DB.
and set a latency on every request DB calls of 1 second.(the set local DB call, actually creates some overhead)Ive not re-run the entire test, instead I've contributed a k6 test, which I used to verify on my local machine; within the also modified docker-compose yaml.
The migrations are still manual; and you'll probably notice I tried increasing server connections. I Think adjusting the
min_sizeof db connections could be another good way to gain performance.I'm pretty sure it still wont top bun, but you could get a few more thousand requests per second