Ok, thread pool might be a little bit over engineering, all we really need is to have 2 dedicated threads, one for collecting data and one for sending metrics to carbon server, and a metric queue in between. One dedicated thread collects data and place them on queue of some user defined size (singe item is a single metric, like request count) and second just picks data from queue and sends it. I don't see any information what happens when uWSGI cache is full, but if it could drop oldest entry (or the one with lowest TTL), than we could use it as simple queue. Since user will be able to push any data to carbon server (or other stats receiver), I think that this will be something much more useful.
2013/3/2 Łukasz Mierzwa <[email protected]> > > 2013/3/2 Łukasz Mierzwa <[email protected]> > >> * wake up every N second (N - carbon freq) > > > It's just important to wake up *exactly* every N seconds, with as little > overhead as possible. This could be dedicated thread or some evened way > (there is a alarm subsystem in linux, I'm not sure if usable for such > tasks). > And after waking up execute carbon_push_stats() for current wall clock > time elsewhere, in a thread. > > > -- > Łukasz Mierzwa > -- Łukasz Mierzwa
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
