I don't want you to stop experimenting but logging a counter seems to have a lot of practical problems to me, especially when it comes to evaluating them.
Carsten 2013/2/27 Ian Boston <[email protected]>: > Hi, > I have done a witeboard impl [1] using Bertrand's Marker idea, based > on the current commons-log bundle (@Bertrand I wasn't sure if I should > take your whiteboard code or not as a starting point). > > Its a simple concurrent map of AtomicLongs, which I suspect wont be to > everyones taste. > There is a servlet which dumps the map out to json using a > StringBuilder to avoid adding any dependencies to logging. > > I am still testing, but so far I dont think there is any non > concurrent behaviour with upto 32 threads, 100 counters invoked a few > M times. Overhead to increment a counter is about 200-240ns on my box > (MBP 2.53 Ghz Intel Core 2 Duo, JDK1.6). I need to get some stats if > there are any blocking waits by threads but from the tests so far > there dont appear to be any. > > > To use it you would do > > public static final Marker COUNT = MarkerFactory.getMarker("count"); > ... > > log.info(Counter.COUNT,"read-property"); > > which adds 1 to the counter "read-property". > > > Ian > > 1 http://svn.apache.org/viewvc?view=revision&revision=r1450676 > > > On 27 February 2013 15:23, Ian Boston <[email protected]> wrote: >> I was thinking of covering this first with a multi threaded unit test >> to verify no concurrency issues and to give an idea of maximum >> throughput, since a centralised counter working off logging API >> markers could be used anywhere. >> >> I will do before after testing as well. >> Ian >> >> On 26 February 2013 17:55, Carsten Ziegeler <[email protected]> wrote: >>> Just a general comment especially on statistics, whatever we do, we >>> carefully need to check the performance impact. Over the past years, >>> I've seen too many approaches where a simple statistics like "number >>> of incoming requests" was a real bottleneck under load (I think one of >>> our first implementations in Sling engine had a similar problem). So >>> while such an information is interesting and important it shouldn't >>> bring down the server or reduce the performance significantly. Doing >>> some benchmarking before and after should do the trick. >>> >>> Carsten >>> -- >>> Carsten Ziegeler >>> [email protected] -- Carsten Ziegeler [email protected]
