This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-16
Channels
- # beginners (7)
- # boot (63)
- # capetown (1)
- # cider (20)
- # clara (15)
- # cljs-dev (5)
- # clojure (195)
- # clojure-austria (2)
- # clojure-dev (46)
- # clojure-dusseldorf (9)
- # clojure-germany (6)
- # clojure-greece (36)
- # clojure-italy (5)
- # clojure-nl (4)
- # clojure-russia (173)
- # clojure-sg (1)
- # clojure-spec (93)
- # clojure-uk (65)
- # clojure-ukraine (2)
- # clojured (9)
- # clojureremote (1)
- # clojurescript (52)
- # core-async (14)
- # core-logic (5)
- # cursive (21)
- # data-science (8)
- # datomic (60)
- # emacs (83)
- # jobs (9)
- # jobs-discuss (7)
- # juxt (6)
- # klipse (2)
- # leiningen (1)
- # lumo (24)
- # mount (4)
- # numerical-computing (1)
- # off-topic (18)
- # om (37)
- # om-next (5)
- # onyx (13)
- # pedestal (1)
- # perun (44)
- # proton (2)
- # rdf (3)
- # re-frame (24)
- # reagent (4)
- # remote-jobs (3)
- # spacemacs (3)
- # testing (6)
- # vim (10)
- # yada (2)
hey all, how should I think about the size of my buffers? should it be close to number of processors? count of the total items to be put onto the chan? something else I’m not thinking of?
we're currently using buffers in two ways - to match the page-size of queries to a database and to limit concurrency in stream-processing - each of those has different sizing requirements
One mechanism a buffer provides is to slow down a producer who’s putting data onto the queue (channel). It’s a way for the consumer to say “hold on, I can’t handle any more work right now” — if a buffer is too large, the consumer will effectively say “keep it coming” even though it can’t do more work, and the producers will happily overload the consumer. However, if the buffer is too small, the producers will be blocked from putting data on the channel unnecessarily, even though the consumer can handle more work. You have to consider the type of work being done — a buffer also provides for brief irregularities in the data flow, without blocking a producer. For example, a short burst of data that a consumer can’t handle immediately is buffered, and as the consumer takes data off the queue, the queue empties. You would not want to set the buffer too small in this case, as it would turn away work that can be done, but that is not coming in at a constant rate.
So, that’s a very general answer to your very general question — the answer is, it depends on the type of work, the rate of flow of the data into and out of the channel, and so on
Also, you want the buffers large enough that you can hide some of the overhead of handing the message from one channel to the other.
For example, in some tests I've performed, systems using (chan 1) ran about 2x slower than (chan 4).
and just try to avoid (chan) at all costs, that one is super slow.
interesting. so number of processors would be a not great choice, but something correlated to the size of the data in a way that the consumers can keep up is the ideal
well maybe not at all costs, just try not to use it.
exactly
My rule of thumb is 100 or 1000 items if the items are "a hashmap with a few items". I think harder about buffersizes if my items are 1MB images.