[
https://issues.apache.org/jira/browse/JCR-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086913#comment-13086913
]
Alex Parvulescu commented on JCR-3040:
--------------------------------------
thanks for all the comments!
the biggest problem with the initial commit (now patch) was that the impact of
the jmx support was unknown in a default scenario where everything is disabled
but there still is an impact on the core operations.
that is what I'm trying to figure out now, as the results of the tests were not
clear.
to me performance with the stats enabled is not an issue in the first
iteration, getting a good starting point is. I also needed to start pushing out
code to be reviewed, as it piled up on my machine which in the end resulted in
a huge commit, and then a huge headache :)
@thomas:
- 10% slower? where did you get the number from? the tests that I ran were
inconclusive, see @stefan's comment
I agree with your observations, but it feels a bit like premature
optimization until we actually get the code into JR core (currentTimeMillis vs
nanoTime, BigDecimal vs double, locks vs volatile).
@stefan
Yes, I'm refactoring to have just one bean (like a dynamic registry) enabled
from the start, which would ideally be able to enable other jmx beans on demand.
I don't like the system property idea, as it kinda defeats the purpose of
having jmx support ootb without a restart.
'slight interest' I should change the description at one point, the priorities
constantly change, so should the issue description.
I also don't see the regression risk, we test constantly for performance
degradation on the core parts, plus we'll disable everything ootb. the jmx
support has a lot of benefits too, I'm sure in the end it will be worth it.
@jukka
- I completely agree on the performance, I still need to run some tests, once
we all agree on what the basis of the jmx support will look like (and where it
will reside).
I'll concentrate on building a really low impact ootb jmx support (disabled and
with a minimal footprint), then we can measure each component and optimize as
needed.
As we appear to be having a vote for or against jmx support in general, I'll
also send an email to the list, to gather some more info on this topic.
> JMX Stats for the Session
> -------------------------
>
> Key: JCR-3040
> URL: https://issues.apache.org/jira/browse/JCR-3040
> Project: Jackrabbit Content Repository
> Issue Type: Sub-task
> Components: jackrabbit-core
> Reporter: Alex Parvulescu
> Assignee: Alex Parvulescu
> Attachments: JCR-3040.patch, jr-test.log
>
>
> I've named them Core stats. This will include:
> - number of sessions currently opened
> - session read / write operations per second
> The stats refresh once a minute.
> This is disabled by default, so it will not affect performance.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
