This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-10-06
Channels
- # aleph (79)
- # bangalore-clj (3)
- # beginners (49)
- # boot (74)
- # cider (10)
- # cljs-dev (21)
- # cljsrn (2)
- # clojure (105)
- # clojure-berlin (1)
- # clojure-brasil (1)
- # clojure-dusseldorf (1)
- # clojure-korea (1)
- # clojure-poland (3)
- # clojure-russia (38)
- # clojure-spec (146)
- # clojure-uk (20)
- # clojurescript (70)
- # cloverage (1)
- # component (1)
- # core-async (23)
- # css (16)
- # cursive (22)
- # datascript (1)
- # datomic (22)
- # defnpodcast (6)
- # emacs (60)
- # events (1)
- # hoplon (94)
- # jobs (1)
- # jobs-rus (13)
- # luminus (11)
- # off-topic (11)
- # om (48)
- # onyx (5)
- # proton (7)
- # re-frame (87)
- # reagent (39)
- # rethinkdb (1)
- # ring-swagger (14)
- # rum (6)
- # specter (14)
- # untangled (105)
- # vim (6)
- # yada (22)
if i wanted to hold onto some state from an aggregation and use it in the next aggregation (say a rolling current_max value to compare against), what would achieve that? I assume something related to the trigger
@lucasbradstreet max:read_log.10s_max_complete_latency / max:read_log.10s_throughput
is this a sensible calculation to perform?
@robert-stuttaford: I'll have to think about it a bit more, but I'm not really sure what it means since multiple segments are in flight at any given time, unlike the other metric we discussed
Sum (all complete latencies over the last 10s) / throughput 10s should approx equal average complete latency, given a steady stream of segments. So you'd be dividing it again by the throughput which I don't think gives you anything useful
thanks, Lucas