jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Parvulescu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3040) JMX Stats for the Session
Date Thu, 18 Aug 2011 09:35:27 GMT

    [ 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

        

Mime
View raw message