jlengrand/bugsink
1
0
Fork 0
mirror of https://github.com/jlengrand/bugsink.git synced 2026-03-10 08:01:17 +00:00
Code Issues Packages Projects Releases Wiki Activity

Note playground.bugsink findings of get_period_counter initialization

Browse Source
This commit is contained in:
Klaas van Schelven
2024-05-23 14:32:30 +02:00
parent fb66b04be9
commit 8b0a4aafe0
2 changed files with 8 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
performance/management/commands/document_performance_insights.py
View File

@@ -153,6 +153,10 @@ This means (surprisingly) we can take our eye off optimizing this particular par
* in the debugserver (integrated ingestion/handling) we don't expect 100k events; and even if we did a 6s delay on the * in the debugserver (integrated ingestion/handling) we don't expect 100k events; and even if we did a 6s delay on the
first event/request is fine. first event/request is fine.
Counterpoint: on playground.bugsink.com I just observed 42s to initalize 150k events, which is ~5 times more slow than
the above. It's also a "real hiccup". Anyway, there's too many questions about period counter (e.g. how to share
across processes, or the consequences of quota) to focus on this particular point first.
Ways forward once we do decide to improve: Ways forward once we do decide to improve:
* regular saving of state (savepoint in time, with "unhandled after") (the regularity of saving is left as an exercise * regular saving of state (savepoint in time, with "unhandled after") (the regularity of saving is left as an exercise

4
performance/out/some_script.txt
View File

@@ -29,6 +29,10 @@ This means (surprisingly) we can take our eye off optimizing this particular par
* in the debugserver (integrated ingestion/handling) we don't expect 100k events; and even if we did a 6s delay on the * in the debugserver (integrated ingestion/handling) we don't expect 100k events; and even if we did a 6s delay on the
first event/request is fine. first event/request is fine.
Counterpoint: on playground.bugsink.com I just observed 42s to initalize 150k events, which is ~5 times more slow than
the above. It's also a "real hiccup". Anyway, there's too many questions about period counter (e.g. how to share
across processes, or the consequences of quota) to focus on this particular point first.
Ways forward once we do decide to improve: Ways forward once we do decide to improve:
* regular saving of state (savepoint in time, with "unhandled after") (the regularity of saving is left as an exercise * regular saving of state (savepoint in time, with "unhandled after") (the regularity of saving is left as an exercise