[OPENAM-10127] SessionMonitoringStore should only be instantiated when monitoring is enabled Created: 02/Dec/16  Updated: 25/Apr/19  Resolved: 22/Nov/18

Status: Resolved
Project: OpenAM
Component/s: monitoring, performance
Affects Version/s: 12.0.0, 12.0.1, 12.0.2, 12.0.3, 12.0.4, 13.0.0, 13.5.0, 14.1.1
Fix Version/s:, 6.5.1,, 6.0.1, 7.0.0

Type: Bug Priority: Major
Reporter: Bernhard Thalmayr Assignee: Mark de Reeper
Resolution: Fixed Votes: 1
Labels: EDISON
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Screen Shot 2016-12-13 at 10.09.54.png     PNG File Screen Shot 2016-12-13 at 11.05.55.png     PNG File Screen Shot 2017-06-29 at 16.06.03.png     PNG File performance-impact-monitoring-login.png     Zip Archive results.zip     Zip Archive results_6.0.0.7.zip    
Target Version/s:
Rank: 1|hzwf9z:
Sprint: AM Sustaining Sprint 41, AM Sustaining Sprint 42, AM Sustaining Sprint 43, AM Sustaining Sprint 44, AM Sustaining Sprint 45, AM Sustaining Sprint 46, AM Sustaining Sprint 47, AM Sustaining Sprint 48, AM Sustaining Sprint 49, AM Sustaining Sprint 50, AM Sustaining Sprint 51, AM Sustaining Sprint 52, AM Sustaining Sprint 53, AM Sustaining Sprint 54, AM Sustaining Sprint 55, AM Sustaining Sprint 56, AM Sustaining Sprint 57
Story Points: 3
Needs backport:
Support Ticket IDs:
Verified Version/s:
Needs QA verification:
Functional tests:
Are the reproduction steps defined?:
Yes and I used the same an in the description


When using AppDynamics to analyse OpenAM's performance during authentication it turns out the one of the most expensive methods is the construction of SessionMonitoringStore, see attached screenshot from AppDynamics.

As it seems the counters are only leveraged by OpenAM monitoring , the objects should only be initiated when OpenAM monitoring is enabled. However this is not the case by default.

Comment by Andrew Vinall [ 02/Dec/16 ]

Bug Triage: Sebastien Bertholet [X] Have you had any experience in this area. Is is an issue we need to follow up on further?

Comment by Sebastien Bertholet [X] (Inactive) [ 02/Dec/16 ]

Not really, but the description of the issue definitly makes sense to.
Expensive objects should not be initiated if not used.
Would be interesting to check if the fix helps to improve authentication performance significantly (wen monitoring is disabled), or if is just a waste of cpu usage.

Comment by Andrew Vinall [ 09/Dec/16 ]

Narita Saxena We have assigned you as QA Assignee as this bug need performance team assessment (regarding the "Verify" label).

Comment by Narita Saxena [ 09/Dec/16 ]

Sure Andrew!.. is this similar to OPENAM-10132?

Comment by Narita Saxena [ 13/Dec/16 ]

Andrew Vinall I did a bit of testing on AM 12.0.4 and 13.5.0 noticed one thing for sure that this object is being initiated with monitoring disabled but also noticed its not in the top 25 object to consume time at. Also there is no performance impact as such on authentication with or without AM monitoring . Im attaching snapshots from visualvm.

it would be worth removing initialisation of these objects but currently not having any performance impact.

Comment by Bernhard Thalmayr [ 24/Jan/17 ]

Narita Saxena I would say that VisualVM is not really comparable with AppDynamics. It might be worth to look at the data I provided. You could also use AppDynamics yourself. It's free of charge for what is needed to analyse this.

Comment by Narita Saxena [ 29/Jun/17 ]

Tried 13.5.0 with app dynamics and seen the same behaviour of SessionMonitoringStore being called even when the monitoring was disabled. Attached are the screenshot.. It does occur on current 14.5 snapshot as well.

Comment by Ľubomír Mlích [ 25/Apr/19 ]

Verified performance is better in AM comparing to AM results_6.0.0.7.zip

Generated at Wed Feb 24 18:22:51 UTC 2021 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.