-
Notifications
You must be signed in to change notification settings - Fork 6
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
Stress Testing Throughput for Club Submission Applications #606
base: master
Are you sure you want to change the base?
Conversation
|
GitGuardian id | Secret | Commit | Filename | |
---|---|---|---|---|
9335321 | Generic Private Key | ede0a26 | nginx/certs/_wildcard.localhost.net-key.pem | View secret |
9335321 | Generic Private Key | 33aa378 | nginx/certs/_wildcard.localhost.net-key.pem | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secrets safely. Learn here the best practices.
- Revoke and rotate these secrets.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
Our GitHub checks need improvements? Share your feedbacks!
|
||
self.uri = "/users/question_response/" | ||
self.factory = APIRequestFactory() | ||
self.view = UserViewSet.as_view({"post": "question_response"}) |
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.
This will create objects for real right? So we want to tear down?
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.
Yeah the tearDown()
function handles that, but if it needs to be more explicit I can do that.
self.users = list(User.objects.filter(username__startswith=self.user_prefix)) | ||
print("Finished setting up users.") | ||
|
||
@sync_to_async |
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.
This decorator is misleading. All this is doing is taking your function and convering it to an awaitable
. It unfortunately doesn't make your code "async for free". In fact, with thread_sensitive = True
(which is the default behaviour), I believe these functions will all run in the main thread, and probably even slower then usual since it goes through the overhead of "asyncifying". Some more information here
It isn't worth changing it back since this is just a test but I thought I should let you know about this behaviour. IIf you wanted better async, you might want to use httpx or something like that (I think newer versions of Django support Async more natively).
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.
Yeah I was starting to notice that in the end. I originally was designing it as sending HTTP requests and was going to use httpx
but then the mocking seemed like a better option. Thanks for sharing!
return end_time - start_time | ||
|
||
def tearDown(self): | ||
Club.objects.filter(code__startswith=self.club_prefix).delete() |
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.
Might have stray ClubApplication
, ApplicationSubmission
, etc objects which you'll need to tear down
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.
Checking from the models, this should all be handled with on_delete
behavior? It should form separate "trees" with roots of Clubs and Users.
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.
Sure, this makes sense. Please do double check empirically though; we should definitely avoid excess footprint on the DB, especially if we test in prod multiple times.
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.
Yeah just double checked, no rows are left over. The only concern I guess could be the autoincrementing index and offsetting that by the number of test instances. Should not be an issue at all, but if we want full isolation, we could create a separate database on the same instance.
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 think this should be fine! Thank you for double checking
Can you post your test results here? |
Great start Shiva! I think we're ready to take some steps towards productionising this test, some notes:
|
Yeah I'm going to conduct more testing tonight, but I wanted to address the async behaviors first and potentially consider doing HTTP requests instead, but if our goal is to isolate database behavior, mocking makes more sense. Will show benchmarks for SQLite and PostgreSQL! |
Took a look, and yeah you're completely correct about I believe the implementation will be highly dependent on the actual database for now. I'm going to try seeing if PostgreSQL functions as is, because I'm not sure how informative SQLite will be if our main goal is to test a database with concurrency capabilities (table-locking vs. row-locking). |
Yeah sounds good. I don't think |
@shiva-menta did we ever have any results on this? Curious about how things match up since we didn't actually seem to have any DB issues in prod this cycle. |
Conduct customizable stress tests using
python manage.py stress_test
. Change parameters including number of users, applications per user, number of clubs, etc.HTTP requests are mocked using
APIRequestFactory
. Tested minimally before and after #603, and saw some performance gains in SQLite, but SQLite's concurrency features should be considered (thread explaining how SQLite handles concurrent writes!). Have not tested on Docker Postgres yet.