On Jan 21, 2014, at 11:56 AM, Paul Viola <vi...@highspot.com> wrote:
> I think this is all well and good for a particular use of channel. > > So perhaps I am misusing channels?? > > To repeat: in one case I have workers pulling from a channel of real work. > For various reasons this channel might get filled rather deeply. In this case > I would want to add additional workers or get a bigger machine. I was > wondering if monitoring the channel for things like average depth (or 99 > percentile) would give me the information I needed. > > Often queue length isn’t a particularly good measure of what’s happening, nor a particularly good indicator of how to solve a problem, or even if there is a problem. You might consider measuring service time more directly by tracking how long requests take to be served. Then you might measure the utilisation of the workers, maybe by measuring how long they wait for a new job and how long it takes to complete a task. These measurements are pretty straightforward to implement in core.async (though it’d be more ‘efficient’ to build them right into channels). What to do in response to these numbers isn’t necessarily obvious (more workers? *fewer* workers? split the queue? faster CPU? More CPUs?) Core.async introduces it’s own problem by banning unbound queues. The strategy of blocking clients as a consequence of maxing out a queue can be bad. So there’s a new problem that you have to deal with, making sure the channel size is big enough to handle any normal situation (which implies you to know what normal actually is, and sometimes you don’t know beforehand). To deal with this problem a channel count would be very helpful. > > I could of course "just skip the channel business, and use a java queue" is a > fine proposal. Well… > > > But since the producers of this work are truly asynchronous (attached to the > real world) I thought it best to keep the channel methodology. > > > > > > > On Tue, Jan 21, 2014 at 5:11 AM, Aaron France <aaron.l.fra...@gmail.com> > wrote: > On 21/01/14 14:09, Moritz Ulrich wrote: > On Tue, Jan 21, 2014 at 9:43 AM, Aaron France <aaron.l.fra...@gmail.com> > wrote: > Since channels yield nil when they are devoid of items, surely this is enough > to know when the channel is empty? > That's not correct. Take-Operations block on empty channels. They > yield nil when they're closed. You could add a timeout to the take > operation to see if no item arrived in a specific time. > > Much appreciated for the clarification. It's the same in Go. > > I can imagine this pattern (take on a possibly closed channel being useful) > being useful but I'm not convinced knowing the count of channel is a safe > thing to know/care about. > > My $0.02, perhaps Clojure does this differently. > > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- You received this message because you are subscribed to a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/zD2jl-bIFXI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
