Note playground.bugsink findings of get_period_counter initialization

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

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
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:
* regular saving of state (savepoint in time, with "unhandled after") (the regularity of saving is left as an exercise

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
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:
* regular saving of state (savepoint in time, with "unhandled after") (the regularity of saving is left as an exercise