[
https://issues.apache.org/jira/browse/ARTEMIS-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16072209#comment-16072209
]
ASF GitHub Bot commented on ARTEMIS-1185:
-----------------------------------------
Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/1295
@clebertsuconic
> So, right now the logic for missing measures is inside
FlushSampleFlyweight.. while it should / should be at the buffer...
The missing logic is already inside the buffer, while the
FlushSampleFlyweight class is a struct-like class to write/read measurements
over a ByteBuffer.
> I have moved the file creationg to MultiCastBuffer.
I'm (re)thinking about putting the file naming/location logic on the
MulticastBuffer and maybe is not the best place there...
To favour the separation of concerns I prefer to leave the buffer without
any other logic than what is needed for the data structure to do its job.
If different parts of the system will require to put all the counters in
one file and/or build something more dynamic to allocate counters on demands,
the MulticastBuffer (and unit tests) won't be touched by these changes.
> Or maybe we could make this generic for not just the journal.. .and still
have a single File.
:100: This is a very good idea!
> This could be extended to other measures.. E.G. Message sending and
consuming... etc.. etc...
Related to this thought, I'm thinking to release other perf counters for
the broker (eg connection bytes sent/received?), but probably this will require:
- to build different file location/naming strategies
- to built a manager to allocate/release dinamically the counters
- to build at least another type of IPC data structure without the missing
recognition features (pretty simiilar to
[AtomicCounter](https://github.com/real-logic/Agrona/blob/master/agrona/src/main/java/org/agrona/concurrent/status/AtomicCounter.java))
Probably using directly Agrona's
[CountersManager](https://github.com/real-logic/agrona/blob/master/agrona/src/main/java/org/agrona/concurrent/status/CountersManager.java)
could be a good idea.
It's a perfect fit for single Long sized messages where isn't needed the
timestamp of the message and is not required to know any accuracy of the sample
(aka missing samples).
When you'll be online we could talk about it (I've a demo to show you about
it) :+1:
> Inter-Process Journal Sampler Profiler + CLI command
> ----------------------------------------------------
>
> Key: ARTEMIS-1185
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1185
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
> Reporter: Francesco Nigro
> Assignee: Francesco Nigro
> Priority: Minor
>
> It provides a sampling profiler on buffered ASYNCIO/NIO based journals.
> The profiling has a minimal cost in term of CPU time for each sample (the
> dominant costs are System.nanoTime() and a single cache line invalidation)
> and total memory footprint (~OS page size in bytes).
> A proper CLI command activates a sampler to collect (ie CSV) the profiled
> data, showing the precision of the sampling: data loss is not considered a
> failure condition.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
