Clarity

A question for the time slice experts out there :). I want to understand the impact of time slice data on the application. If you were to decrease the amount of slice date stored in the system, where would you expect to see a performance impact. I would expect to see improvement in the system jobs like datamart jobs, datawarehouse jobs, investment allocation etc. Where in the application side will there be an impact if any.

Firstly when the slices roll over then the sluggishness will last a shorter time.

Secondly any data that is coming from the slices will be up to date faster.

Thank you urmas.

Yeah I would NOT expect to see any performance improvement in any of the jobs you mention.

Time slicing is really a "helper" function to help some screens be able to display data easily. The core system jobs that move data through the system are unaffected since they are working on the underlying data (not the sliced data).

Where you would see system performance is in general performance terms, in that the timeslice job would not be consuming system resources as much ; but to be honest if you have your system setup well then this shouldn't really be an issue. i.e. If you do have performance issues then I would be tuning my system first before trying to tune timeslicing as a way of mitigating these.

(The functional impact of changing timeslice settings needs to be understood if you are going to do anything with them too)

David,

I thought the data mart job uses the daily time slices and we had them set up to go way many years out in the future. So I was hoping that it would run quicker.

This was one of the initiatives to address performance issues. We addressed the setting on the database side first. We then are looking at the time slices now. We were going to remove 20+ million rows of slice data that was really not being used by setting slices just so they met our business needs and nothing more, so i was hoping i would see some impact on our jobs..

Which other areas to your knowledge have you seen the most performance impact on.

Thanks so much for you insight on this. Truly appreciated.

Smitha

Our performance issues were not slice related, but too much audit data, complex queries, too many customizations, complex security model, etc.

Thanks Michael. I agree on the complex queries and the security model. If you do not mind, can you share how audit data caused your performance impact, was it the no of fields or the length you were retaining data for. We have about a million + records of audit data and i wasnt sure how much that could contribute to performance.

Are you using the Purge setting when adding attributes for audit ? If no, I guess that you define this option, else, performance would definitely degrade.

Although a bit old, check this as well:

Clarity performance

Regards

NJ

Thank you! We do have the purge setting. I was wondering if anyone had done some analysis or  found from their experience a "threshold" of no of fields to audit or the length of time before purging, that alleviates the performance impact.

Thank you for sharing the presentation. I have used this as a reference for our initiative as well. This is one of the best performance related deck I found online .

Hi Smitha,

See the content if this helps I tried to cover length and breadth of the product in terms of performance.Purging entirely depends on how long you need audit data.

CA PPM Performance tuning webinar

Regards
Suman Pramanik

Great Presentation. Thanks Suman!

Best Regards,

Smitha

Thank you for the feedback

Unfortunately we have not purged any audit data so we have about 40 GB worth of it. on my trainignn system where I have purged it I have better performance.

Hi smitha.narreddi - Did any of the responses help answer your question? If so please mark as Correct Answer. Thanks!

Thinking more of it the length of the time frame in the slice is not likely to affect the roll over.

That is the rollover is always one period and not dependent on the total number of periods.

What counts is how many slice request you have (you could set the slice requests you do not use not to roll and have minimum data) and how many object instances with blob data to be sliced you have.

When you create new items then the initial slicing will take longer the longer your time frames are. The blobs are going to be the same regardless of your slicing or if you do not slice at all.

Those jobs which are incremental are not going to be affected by the length of the time frame in the slices. Those which do full data transfer like the initial population of the datamart are.

I was under the impression that  the amount of audit data creates only dead db overhead except when you open the audit trails and have a faint recollection of having asked that, too, somewhere.

In https://communities.ca.com/message/100691596#comment-100691596 mike2.2 you write that at the time you did not see audit trail with that number of attributes and data to make a difference in performance.