mirror of
https://github.com/jlengrand/bugsink.git
synced 2026-03-10 08:01:17 +00:00
42 lines
1.8 KiB
Plaintext
42 lines
1.8 KiB
Plaintext
## _prev_tup()
|
|
|
|
1_000 iterations of _prev_tup in 0.832ms. The main thing we care about is not this little
|
|
private helper though, but PeriodCounter.inc(). Let's test that next.
|
|
|
|
|
|
## PeriodCounter.inc()
|
|
|
|
1_000 iterations of PeriodCounter.inc() in 7.885ms. We care about evaluation of some event more though. Let's
|
|
test that next.
|
|
|
|
## PeriodCounter.inc()
|
|
|
|
1_000 iterations of PeriodCounter.inc() in 29.567ms. (when 3 event-listeners are active). I'm not sure exactly
|
|
what a good performance would be here, but I can say the following: this means when a 1,000 events happen in a second,
|
|
the period-counter uses up 3% of the budget. A first guess would be: this is good enough.
|
|
## get_pc_registry()
|
|
|
|
getting the pc-registry takes 6615.371ms. (with the default fixtures, which contain
|
|
|
|
* 10 projects,
|
|
* 1000 issues,
|
|
* 100000 events
|
|
|
|
This means (surprisingly) we can take our eye off optimizing this particular part of code (for now), because:
|
|
|
|
* in the (expected) production setup where we we cut ingestion and handling in 2 parts, 6s delay on the handling server
|
|
boot is fine.
|
|
* 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
|
|
to the reader)
|
|
* more granular caching/loading, e.g. load per project/issue on demand
|
|
|