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]
