Idea Details

Add transaction response time in policy server smaccess audit log

Last activity 06-04-2019 12:07 PM
stephen.mcgilligan's profile image
07-09-2018 08:29 AM



In a similar way to how web servers record the response time for a transaction it would be really useful if CA SSO did the same within the smaccess audit log.


This would allow us to improve pro-active monitoring, debugging and tuning of the policy server engine.





03-15-2019 05:35 AM

Hi Hubert,


Apologies, just seeing this. I was referring to the total time for the transaction e.g. AuthAccept, AzAccept etc. These are logs we're already spooling to log collectors for analysis so being able to chart the response times of those events allows us to do quite a bit of investigation without tracing.


The existing execution threshold setting is OK and does let us trap logs for transactions that overrun but to be honest it's a little coarse. The 2 approaches would likely complement each other rather than replace.


How you calculate all depends on how you thread internally I guess.




08-24-2018 10:49 AM



Audit logs prints one line result for the entire transaction.  


By "Response Time for a Transaction" we mean the total time taken for execution of a Transaction - correct ?


e.g. A single TransactionID (Tid) in smtracedefault.log.



Asking this for clarity, as currently in smtracedefault.log we do print execution times. Hence trying to gauge the performance offset of


......enabling a minimum set of values in tracing (which would provide execution times at sub event level within an entire transaction) VS just printing an overall execution time of an entire Tid (which to me means, I'd still need to dig what cause the overall increase in execution time by scouting sub execution times in trace log).


......if it does get added into audit log, the new lines of code (at worker threads) that would do the job of collating the Tid thereafter putting it into a Async Queue for Write to a file / AStore VS enabling a minimal set via smtracedefault.log - which one is better performant (such thoughts would need to be considered when devising this feature).



Have we looked at execution threshold times feature that was incorporated into smps.log. What is tradeoff between that feature in smps.log and this one being requested ? Again if this feature being requested gets implemented in audit logs, we would need to ascertain the benefit of printing similar (purpose) info at two places i.e. smps.log and smaccess.log (such thoughts would need to be considered when devising this feature).






08-24-2018 09:53 AM

Way overdue. This should've been done long time ago. I hope we see it in the upcoming release. Give administrator ability to turn on different options like: complete transactional time, partial time includes or excludes times to process backend to user stores, etc...

08-24-2018 01:35 AM

Thank you for your contribution of an enhancement idea to the CA Community. CA is continually working to improve its software and services to best meet the needs of its customers. Your input is vital to that effort. The CA Single Sign-On Product Management team is reviewing your enhancement suggestion following the process outlined here: 

The Community will continue to be able to vote on this enhancement idea.