[LRUG] Queuing systems

[Neil Middleton]

Everything processed in order. Generally jobs are similar to analytics data, and are processed to provide a similar sort of stats set.

Every single job needs to be processed. 

Neil

On Wednesday, 7 September 2011 at 10:29, Graham Ashton wrote:

> On 7 Sep 2011, at 10:18, Neil Middleton wrote:
> 
> > Hundreds, possibly thousands of new jobs per second.
> 
> I was actually wondering in terms of bytes per second, but that's still a useful answer.
> 
> I know I'm still avoiding the question here, but I'm now wondering how you're thinking of going about processing them. That would probably have an impact on how I'd approach queueing.
> 
> i.e. If your job processing component went off line for six hours for some reason, would it (when it came back up) be more important to process the earliest queued data, or the most recent data?
> 
> If your job processing stuff got a long way behind would it make sense to drop really old jobs and just start on recent stuff? I'm wondering if this data needs persisting to disk, or whether you can get away with stashing it in RAM (possibly in a persistence backed key value store like Redis).
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org (mailto:Chat at lists.lrug.org)
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20110907/0468c0e7/attachment-0003.html>