Clarity

Hi,  i want to know what is the time taken by Slice Job in other organisations / companies who use clarity.In our case it takes 5-6 Hours.(7.5.2) now started moving to 12.0.5. we have set the timeslices some what meaningfully (TEC435572) but still takes that time.I know the time taken is depend upon the timeslice settings and also the volume of data and the power of the Box etc.  But just want to know from other users that what's the time normally takes or what shouldbe the right time? why iam asking is that the data shown from slices should be an Near Live Data (may be 1 or 2hour delay is ok) and should not be an 1 day delay.(Like ours..)  Suggestions welcome..  cheers,sundar

Hi Sundar.We slice every 5 minutes.   crontab: */5 * * * *   We're a small shop (~500 users) running the "Small Architecture" as documented in the admin guide. Slicing only processes what needs updated, and because our slicing is so frequent the timeslice job takes seconds or less. This is near real time enough for us.    We slice 730 daily periods, 208 Weekly Periods, 49 Monthly & 20 Quarterly. This gives us a year look  back & ahead  in the dailys and around 2 years in all others.    We're Clarity 12.05 on Win2K3/MSSQL2005. Our app server and sql server are VMs, so "power" is relative to how many VMs are sharing the box. It's modern big iron so it's been more than adequate.    Like the article points out, we make it as easy on our system as we can by cleaning up after ourselves. We zero out remaining  assignments and allocations during project closure, transfer or zero out remaining  assignments and allocation  on resources who leave the organization.  The article doesn't mention good open time period practices.  Time Slicing builds forward from the point of earliest change, so the tighter  one keeps their open time periods window, the less oportunity for historic change.  We keep a "rolling wave" of 7 open time periods (4 back, current week, 2 forward).  HTH

HTH  Can you explain what you mean by historic change?We set out time periods to follow Ulti pro -- and it is rather tights,, are at risk for something?  The article doesn't mention good open time period practices.  Time Slicing builds forward from the point of earliest change, so the tighter  one keeps their open time periods window, the less oportunity for historic change   thanks

As I understand it , time slicing and the datamart "build forward" from the last point of change. If, "User A" has one week of unposted time 9 months ago, and one were to go in and post that week, all affected time slices will wipe clean then rebuild forward from the point of that change. Long story short: Historic change leads to heavy system processing. Disciplined time entry and a tight rolling wave of open time periods is not just cultural, it affects Time Slicing system performance as well.  Tech Gurus please feel free to correct me if I'm wrong.

 ^ I hope thats not right!  [ I know timeslices get totally rebuilt when you redefine the structuire of the timeslice, but not when you just add some more user-data to the system. I can't comment for the datamart though as we turned it off a while ago (!!) ]  I was interpreting "historic change" just as; if you only have 2 weeks of open time periods open in the past, then you can only make "historical change" (i.e. timesheet adjustments) back 2 weeks.    -------  EDIT and just to reply to the original question.....  "it depends"  We run the timeslicing job "continuously" (every minute) during "working hours"... if there is nothing for it to do, it just shuts down and starts up the next minute again.   When the system is busy (Friday afternoons = lots of timesheets, lots of plan updates = lots of things to slice) the job will take a number of HOURS to run through once (by which time more things need slicing).   And at month / week "rollover" the first run of the job will take a number of HOURS to run through, just to handle the rollover (so we schedule a job to run just after midnight on the first of teh month and first day of the week so the rollover happens overnight).  We also built a simple screen that counts the number of records that need processing (this is just a very simple grid portlet dunping the counts generated by (eg)  SELECT COUNT(*) FROM PRASSIGNMENT where slice_status = 1               -- number of assignments that need slicingSELECT COUNT(*) FROM PRASSIGNMENT where slice_status = 2             -- number of assignments that are being sliced NOWSELECT COUNT(*) FROM PRASSIGNMENT where slice_status = 3             -- number of assignments than need rollover  etc - you can extend that to all the slice-able objects (PRTEAM, PRTIMEENTRY etc etc ).  and I can sit and watch that screen all day on a bad day!!   :-(    

Thanks guys.  Of Course the SLICE JOB is taking long time in all the weekends,Month end adjustment.The key thing isour Actuate Reports in which some resource driven reports in which the resource availablity is the key and as resources are created daily we need the slices badly.  Timesheeting is mandatory and key and if missed it would impact the resource performance too.if any resource inputs less than his availability then his RM /PM would have hit in his project chargeability as we are doing recharge based on the Timesheet actuals.  we also need our time slice for our custom datamart from where our custom reports fetch data and show.  Any way iam waiting for our new v12 env with an Powerful server (The sytem is totally slow not only Timeslice as our Current Box is old one which is setup 6 yrs back) and let me see what time it takes.Any difference would be good,hopefully it should not be worse.  Cheers,sundar

My recollection from a r8.1.fp03 system on MS SQL and single server with 500 users and 600 projects with time slicing run every 5 minutes was 1approx 1,5 minutes and affter timesheet posting maybe 2,5 mins but never more than 5 minutes.  Martti K.

Dave:  How many records per minute is you system processing?  Have you measured how many timesheets get posted per minute?  Martti K.

Martti - Its hard to say "how many" as it really varies through the week depending on the timesheet activity.  But we push through 3000+ timesheets a week, posting every 1/2 hour, so every half hour there are a lot more ASSIGNMENTS to process.   And unfortunately (don't ask!) my Daily ETC slice has 280 periods in the future, so this is where I see most of the processing.  Roughly, 100 timesheets per half-hour = 1000 assignements per half hour + any other updates due to plan changes (allocations don't seem to take as long).   And thats about the "limit" of what I can cope with, so if I get more than 100 timesheets posted in a particular half-hour, the system starts to "back-up".   It all clears itself OK once people go home for the day and stop posting timesheets... but Friday afternoons can be a bit painful!  Also I am trying* to get some (pretty detailed) statistics about how long my rollover takes (and where the rollover is spending its time) to see if I can improve that (I get problems at month rollover, not so bad at weekly).   (I'll post any interesting findings in this thread).  * - I should have had the statistics this week, but I messed up the job that was running in the middle of the night to capture the statistics   - D'Oh, try again!!  Dave.

Dave  I would be very interested in your findings regarding the monthly rollover, I'm sure others will be too.  - just a thought -  Regarding Friday afternoon do you need to maintain the same cycle of timeslice updates during that period?I have not played with at all, but could you have a cron cycles for Mon-Thur and another for Fri (and another for the weekend?). Would this assist at all?  This of course is not going to alleviate any rollover issues.    

Actually the execution of timeslices itself doesn't cause me too much consternation itself (its running continuosly through the working day) - my real problem is that I have a twice-daily interface that sends DAILY actuals off to another corporate time system, and this reads data from a custom DAILY TIME ENTRY timeslice (the custom one that everyone creates anyway!).  So for my interface to run successfully, I have to wait until the slicing is finished for the DAILY TIME ENTRY before I can extract the data, and even though that slice runs through really quickly, it gets "queued" behind the other "long running" slices (DAILY ETC mainly).  (...and hopefully I've put the right path (this time!!) in my batch job to run in the early hours of Monday morning to get those rollover stats!   :-) )  Dave.

Some data in cas you are interested  r81fp03 single app server MS SQL 2005 on separate server500 timesheets, weekly posting, time to run the post job 1 min 30 secs, 2500 rowsTime slicing to set run every 5 minutes.Next time slicing after posting 8.5 minsTransaction post to finanicals 50 secondsPost incidents to financials 4 secsPost to WIP 12 secsGenerate invoices 65 secsDatamart extraction run after that 290 secs  Martti K.  

No good recollection on timeslices, but generally I likedaily actuals one full year backdaily ETC one full year aheaddaily baselines one year back and one year aheadMonthly and weekly the same.  If you want to level the system routine work load so that everything is not launched at the same time and then nothing for a while you have to set the slices accordingly.  Same way as the jobs the OOTB tendency for the slices is that everything rolls over at the same time,... and you can't even select the time of day.  The best you can do is to stagger the start date and configure the number of periods so that they still cover those time ranges and a few days more.  The same way you would stagger the jobs so that they do not fire all at every full hour. Like in my case if the timeslicing after time sheet posting takes longer than the frequency of timeslicing then you would schedule the timesheet posting to start just before time slicing so that there is time to process all timesheets before the time slicing starts and again adequate time for that to finish before allocate investments starts.  As far not scheduling the jobs 24 7 goes why and how would you do that.You would do that to lower the load from peak hours, but the problem is that timeslicing and inversments allocations and hierarchies process the data that is needed during the peak hours so you can't schedule those to off peak hours only and performance is not an issue off peak hours.What you can do is schedule the once a day or once a week or once a month jobs like datamart and some of the EVM jobs staggered of peak hours and again with enough interval for each to finish before the previous one and not coninsiding with rebbots after schedule MS security patch installations. The clena user sessions job you should schedule as the last job of the night just before users start logging in to minimize the number of sessions.  But educate me why do you run time sheet posting more often then once a timereporting period?If you do there is no quarantee that any of the projects are at exactly comparable state at any time if they have an artibary amount of hours posted any time.You could argue that the sooner you post your hours the sooner they get billed.Normally if you bill by the hour it does not mean that you send bills by the hour. On the contrary you may have weekly time reporting periods but still the invoicing is done once per the fiscal periods of accounting.Why woulld you post timeshets every hour.  Martti K.

 Martti - some simple answers to your "But educate me why do you run time sheet posting more often then once a timereporting period?" - well we run posting every half hour because we just want the data on the plans to be as upto date as possible.   ( Our prime reason for Clarity is as a PM-planning tool (and secondary reason as a timesheeting system) - but we don't "bill" from Clarity from example.)  --  My "rollover" stats for this Monday were very unexciting.   All I could see rolling over in the early hours of Monday moring were the PRTEAM records; I had about 75000 records for rollover at just after midnight and these were processed by an hour later.   There was a brief moment of 125000 PRJ_BASELINE_DETAILS requiring rollover, but these processed very quickly.   And thats all I could spot!  (I was gathering stats every 15 minutes over 16 tables (all the ones with a SLICE_STATUS column), so there is a possibility that other slices were missed completely.)  I think my real interesting stats will come at monthly rollover, which luckily is on a Saturday this month (so no pain for my users); I'll try to get some much more interesting stats then!!Dave.

OK I picked up some stats about the timeslice ROLLOVER at the start of this month (May2010)...  I grabbed the number of records with the "Slice Status" column set to "3", every 15 minutes across a load of tables.  The following tables saw a lot of action, and in order processed the following (where the number of records indicates how many records had slice status of "3" and the time represents how long it took until that number got down to zero (and the next slice started));  PRASSIGNMENT.SLICE_STATUS (32478 records) 1.75 hrs
PRJ_RESOURCES.SLICE_STATUS (28561 records) 1.5 hrs
PRTEAM.SLICE_STATUS (52833 records) 4.75 hours BUT did not apprear to process any records for the first 2.25 hrs?
PRJ_BASELINE_DETAILS.SLICE_STATUS (178167 records) 0.75 hrs
PRTEAM.INCIDENT_SLICE_STATUS (76549 records) 0.25 hours

The following sis not appear to have any rollover (o the rollover all happened in less than 15 minutes)
CAP_SCENARIO_ASSIGNMENTS.SLICE_STATUS  
CAP_SCENARIO_TASKS.SLICE_STATUS  
CAP_SCENARIO_TEAM.SLICE_STATUS
CAP_SCENARIO_TEAM.HARD_CURVE_SLICE_STATUS  
INV_INVESTMENTS.SLICE_STATUS
PRCALENDAR.SLICE_STATUS
PRJ_BASELINES.SLICE_STATUS
PRJ_TENTATIVE_ASSIGNMENTS.SLICE_STATUS  And I messed up my script (again) so missed gathering the stats for the following "slices";PRTEAM.HARD_SLICE_STATUS
PRTIMEENTRY.SLICE_STATUS
RSM_REQ_REQUISITIONS.SLICE_STATUS  
SRM_RESOURCES.SLICE_STATUS    (D'oh.)  Conclusion?  the PRTEAM.SLICE_STATUS looks suspect to me, especially where in did not appear to be doing much for 2 hours!?!

Thanks Dave.That'll be the standard for all future comparisons.  Martti K.