Scheduler Performance Paper

Transcription

1 Scheduler Performance Paper Best Practices Version 1.0

2 Disclosure All performance data contained in this publication was obtained in the specific operating environment and under the conditions described above or below and is presented as an illustration. Performance obtained in other operating environments might vary and clients should conduct their own testing. The information contained in this document is distributed AS IS, without warranty of any kind. 2

3 Overview Maximo Scheduler is a function rich product that includes significant data manipulation through the usage of an analytic engine. Due to this combination, the actions taken to optimize performance will have a significant effect on end-users. This presentation provides an overview of actions that should be considered when using this product. We recognize there are additional actions to optimize performance and we are not advocating abandoning those actions. This presentation addresses the following topics: Scheduler Architecture Scheduler Use cases What Contributes to Scheduler Performance Additional Actions to Improve Performance Expected Performance ifix Performance Improvements 3

4 Scheduler and Key Architecture Use Cases 1. The Scheduler product supports a use case that enables a planner to plan the work and make changes to the work. When the planner considers the changes to be acceptable, only then will the changes be applied to the work to be carried out. To support this refinement of changes and to deal with potentially high volumes of data, the design uses an intermediate data store (SKD-tables) to pull all relevant data in one place. This also required an incremental update of this intermediate data with respect to the changes that the planner is making to the schedule and the new work coming in as well as work that s getting changed. 2. The Scheduler product supports a use case for allowing smoother interaction to manipulate the data, which required the design to load all this data into a view on the browser and have this data sorted in a usable form. 3. The Scheduler product supports a use case for minimizing the memory footprint on the Server, which required the design to not store the data on the server, but only the changes that the user is making to the data. 4. The Scheduler product supports a use case for showing the latest details of the Work, which required the design to fetch Work data and merge with the SKD-table data. 1 Gantt View Maximo Server Maximo Scheduler Component 3 SKD-tables Tables that store key information 2 Calendar Tables Work Mgmt Tables Tables that contain Work details Availability Info Tables 4 2 Maximo DB Tables that contain Working times and breaks Tables that contain Asset and Location Availability 4

5 Key Architecture Use Case Details 1. The Scheduler product supports a use case that enables a planner to plan the work and make changes to the work. When the planner considers the changes to be acceptable, only then will the changes be applied to the work to be carried out. To support this refinement of changes and to deal with potentially high volumes of data, the design uses an intermediate data store (SKD-tables) to pull all relevant data in one place. This also required an incremental update of this intermediate data with respect to the changes that the planner is making to the schedule and the new work coming in as well as work that s getting changed. An example showing the incremental changes that need to be adjusted to the intermediated data store. Also, scheduler allows multiple records to be changed, which requires each and every record to be saved independently and also committed independently (requires separate SQL for each change) Before Work order no long meets query After Work order dates modified outside schedule New work order satisfying the query 2. The Scheduler product supports a use case for allowing smoother interaction to manipulate the data, which required the design to load all this data into a view on the browser and have this data sorted in a usable form. Loading all the needed data into a view requires all the data to be fetched from the server, which depends on the size of work data being planned within a schedule. 3. The Scheduler product supports a use case for minimizing the memory footprint on the Server, which required the design to not store the data on the server, but only the changes that the user is making to the dat. This is a good thing for the server, but requires all data to be fetched from the server to be locally available on the browser.. 4. The Scheduler product supports a use case for showing the latest details of the Work, which required the design to fetch Work data and merge with the SKD-table data. 5 Fetching not only the SKD-table data, but also the work data and merging takes time. Also, cleanup of some missing data based on business rules, introduces extra processing on each work data. An example is fixing the schedule dates if they are not filled in.

6 Scheduler (Planner) Use Cases 6

7 Graphical Assignment (Supervisor) Use Cases 7

8 Scheduler (Forecaster) Use Cases 8

9 What Contributes to Scheduler Performance? Total rows fetched How queries are constructed Database indexes Health of the database System environment 9

10 Total Rows Fetched Each of the following points can impact the performance of the application by increasing the amount of data fetched and/or time to retrieve from database: Work Rows Work orders with 4 tasks equals 5 records to fetch How many total work order records are there in the database? Is the work order information properly indexed? Reservations (resources) labor, tools, materials Calendar Periods (shifts x range in days) Number of work periods is large for long calendars Number of work periods is large for multiple shifts Number of work periods can be quite large for multiple shifts over long calendars 10

11 Common Query Patterns This is a best practices section on constructing good queries based on the most commonly used attributes including siteid, woclass, wonum, wplabor, worktype, assets, location hierarchy, status, date ranges, labor, and persongroup (for example). Many queries originate in Work Order Tracking, which is fine; but the user should be aware that standard work order tracking queries are modified by Scheduler, making some parts of the clauses redundant. Specific considerations include: Scheduler adds history flag = 0 (no closed or cancelled work orders come in) Scheduler always brings children as well as tasks (based on the includetasks flag) therefore you don t need to include the statement istask = 0 Scheduler, depending on the data source being used, will automatically add the woclass. So you do not need to add woclass filters. Avoid using subselect when not needed; examples synonym domain (synonym values) and siteid (user defsite) Avoid using a leading % when possible; by default queries created by Maximo use like %ELECT% change to either an = ELECT or like ELECT% On the next few pages are common query patterns seen in many Scheduler use cases. First the standard wotrack example is listed with the extraneous parts of the clause in red, and with comments. Then the corrected example is listed. All examples in the subsequent slides are shown as Oracle queries Backup slides have the equivalent DB2 11

12 Common Query Pattern Example 1 Example 1: Bring in non-closed work orders for the next 7 days Siteid = (select defsite from maxuser where userid = :user) and (woclass = 'WORKORDER' or woclass 'ACTIVITY') and historyflag = 0 and istask = 0 and status in ('APPR','COMP','WPLN','WCOND','WDOC','WMATL','WSCH','SCHD','INPRG') and targstartdate <= (sysdate+7) and targstartdate >= (sysdate) The woclass, historyflag and istask portions of this standard wotrack clause can be removed, because Scheduler adds them itself. Note when using a :user substitution, the schedule data is best kept private to one user due to contraints like data restrictions. There is no guarantee the data will be the same between users/sessions. Listing all the non-closed statuses is not necessary. They are covered by Scheduler s use of history flag = 0 so this extra condition is not needed. Cancelled and closed work orders have a history flag of 1. This clause is excluding WAPPR only - so it might be better as the simpler status!= WAPPR The shorter version of the query will be: Siteid = (select defsite from maxuser where userid = :user) and status!= WAPPR and (targstartdate <= (sysdate+7) and targstartdate >= (sysdate)) 12

13 Common Query Patterns Examples 2 & 3 Example 2: Bring in high priority work for all but one work type worktype <> 'TYPE1' and ((woclass = 'WORKORDER' or woclass = 'ACTIVITY') and historyflag = 0 and istask = 0 and siteid = 'ABC' and wopriority = 1) The shorter version of the query will be: worktype <> 'TYPE1' and siteid = 'ABC' and wopriority = 1 Example 3: Mechanical work that is scheduled either on work orders or tasks in a particular site ((status = 'WSCH' or status = 'SCHD') and (woclass = 'WORKORDER' or woclass = 'ACTIVITY') and historyflag = 0 and istask = 0 and siteid = 'ABC') and (exists (select 1 from maximo.wplabor where ((craft = 'MECH')) and (exists (select 1 from workorder yy where ((yy.istask = 1 and yy.parent = workorder.wonum ) or (istask = 0 and yy.wonum = workorder.wonum)) and wplabor.wonum = yy.wonum and yy.siteid = workorder.siteid) and siteid = workorder.siteid))) Again, we can eliminate woclass, historyflag and istask because Scheduler covers those. The shorter version of the query will be: ((status = 'WSCH' or status = 'SCHD') and siteid = 'ABC') and (exists (select 1 from maximo.wplabor where craft = 'MECH')) and (exists (select 1 from workorder yy where wplabor.wonum = yy.wonum and yy.siteid = workorder.siteid) and siteid = workorder.siteid) 13

14 Common Query Patterns - Example 4 Example 4: All work orders under a certain parent location and belonging to particular persongroups status in ('WSCH','APPR','WMATL','WPCOND') and worktype not in ('OTHER ) and istask = 0 and siteid in (select defsite from maxuser where userid = :user ) and (location in (select location from locancestor where ancestor = 'ABC') and (:user in (select respparty from persongroupteam where persongroup = 'PLANT')) or location not in (select location from locancestor where ancestor = 'ABC') and (:user in (select respparty from persongroupteam where persongroup = 'FIELD')) The shorter version of the query will be: status in ('WSCH','APPR','WMATL','WPCOND') and worktype not in ('OTHER ) and siteid in (select defsite from maxuser where userid = :user ) and (location in (select location from locancestor where ancestor = 'ABC') and (:user in (select respparty from persongroupteam where persongroup = 'PLANT')) or location not in (select location from locancestor where ancestor = 'ABC') and (:user in (select respparty from persongroupteam where persongroup = 'FIELD')) 14

15 Common Query Patterns Example 5 Example 5: Scheduled status for several numbered assets. (worktype <> 'ABC') and ((status like '%SCHD%' and (woclass = 'WORKORDER' or woclass = 'ACTIVITY') and historyflag = 0 and (assetnum like '% %' or assetnum like '% %' or assetnum like '% %') and istask = 0 and siteid = 'SITE1')) In this case, there is a penalty to using the like statement. Like '%...%' or like '%...' will cause the index on the column to not be used, meaning a full tablescan must be performed which can make the SQL slow. But for like '...%', the index will still be used. The shorter version of the query will be: (worktype <> 'ABC') and ((status = 'SCHD' and (assetnum like ' %' or assetnum like ' %' or assetnum like ' %') and siteid = 'SITE1')) 15

16 Common Query Patterns Example 6 Example 6: Approved and in-progress crew work from next Monday through Sunday (the specific syntax of this will vary between databases). select * from workorder where (siteid = 'SITE1' and historyflag=0 and istask=0 and woclass in ('WORKORDER', 'ACTIVITY') and ((((SCHEDSTART BETWEEN NEXT_DAY(TRUNC(SYSDATE),'MONDAY') AND NEXT_DAY(TRUNC(SYSDATE+7),'SUNDAY')) and status in ('APPR','WMATL'))) or Status = 'INPRG') and AMCrew = 'CREW1'); The shorter version of the query will be: select * from workorder where (siteid = 'SITE1' and ((((SCHEDSTART BETWEEN NEXT_DAY(TRUNC(SYSDATE),'MONDAY') AND NEXT_DAY(TRUNC(SYSDATE+7),'SUNDAY')) and status in ('APPR','WMATL'))) or Status = 'INPRG') and AMCrew = 'CREW1'); 16

17 Common Query Patterns Examples 7 & 8 Example 7: Work orders that are approved, complete or in progress from 45 days ago to 45 days in the future. The specific date syntax will vary between databases. ((woclass = 'WORKORDER' or woclass = 'ACTIVITY') and siteid = (select defsite from maxuser where userid = :user ) and historyflag = 0 and istask = 0 and status in ('APPR','COMP','WPLAN','WMATL','WSCH','INPRG') and targstartdate >= (sysdate-45)) and targstartdate <= (sysdate+45) The shorter version of the query will be: siteid = SITE1 and status in ('APPR','COMP','WPLAN','WMATL','WSCH','INPRG') and targstartdate >= (sysdate-45)) and targstartdate <= (sysdate+45) Example 8: Work orders waiting scheduling by work type for a workshop in a site, for the next 2 weeks. status in ('WSCH') and (woclass = 'WORKORDER' or woclass = 'ACTIVITY') and worktype in ('A','B','C','D') and historyflag = 0 and istask = 0 and (siteid = 'SITE1') and (maintshop ='SHOP1') and trunc(targstartdate) between trunc(sysdate) and trunc(sysdate+14) The shorter version of the query will be: status in ('WSCH') and worktype in ('A','B','C','D') and (siteid = 'SITE1') and (maintshop ='SHOP1') and trunc(targstartdate) between trunc(sysdate) and trunc(sysdate+14) 17

18 Common Query Patterns Example 9 Example 9: Approved electrical craft work in a specified date range for 2 PMs. ((woclass in (select value from synonymdomain where domainid = 'WOCLASS' and maxvalue in ('WORKORDER','WOACTIVITY')) and historyflag = 0 and istask = 0 and siteid = 'BEDFORD')) and (((status = 'INPRG' or status = 'WSCH' or status = 'APPR') and targstartdate <= ' :00:00.000' and siteid = 'BEDFORD' and targstartdate >= ' :00:00.000' and (pmnum = 'IC-11200' or pmnum = 'IC-11300')) and (exists (select 1 from maximo.wplabor where ((craft like '%ELECT%')) and (exists (select 1 from workorder yy where ((yy.istask = 1 and yy.parent = workorder.wonum ) or (istask = 0 and yy.wonum = workorder.wonum)) and wplabor.wonum = yy.wonum and yy.siteid = workorder.siteid) and siteid = workorder.siteid)))) Replace wildcards where possible. In this case a better query will be: siteid = 'BEDFORD')) and (((status = 'INPRG' or status = 'WSCH' or status = 'APPR') and targstartdate <= ' :00:00.000' and siteid = 'BEDFORD' and targstartdate >= ' :00:00.000' and (pmnum = 'IC-11200' or pmnum = 'IC-11300')) and (exists (select 1 from maximo.wplabor where ((craft = 'ELECT')) and (exists (select 1 from workorder yy where wplabor.wonum = yy.wonum and yy.siteid = workorder.siteid) and siteid = workorder.siteid)))) 18

19 Health of the Database Scheduler can be very database intensive and there are many things a customer can do to improve the health of their database for overall performance Indexes should be created on columns which are used in filters and joins to accommodate each customer s use cases Chapter 5 in the Best Practices for System Performance document has information on how to tune the database for optimal performance mmunityuuid=a9ba1efe-b a181d6155e3a#fullpagewidgetid=w5f281fe58c09_49c7_9fa4_e094f86b7e98&file=c51d5 f5b-dea a81f-d5213fc

20 Health of Database - Recommended Indexes Available IFIX 7503 IF034, 7504 IF014, 7505 IF008, and 7506 IF001 A new index, WORKORDER_TESTIDX2, for the Workorder Object based on: INCTASKSINSCHED ASC SITEID ASC WONUM ASC Available IFIX 7503 IFnext, 7504 IFnext, 7505 IFnext, and 7506 IFnext A new index, WORKORDER_TESTIDX1, for the Workorder Object based on: SITEID ASC ISTASK ASC WOCLASS ASC STATUS ASC HISTORYFLAG ASC (These Indexes may also be added manually using the Database Configuration application) "Make sure database statistics are up to date" is a general rule for the whole Maximo schema. Especially when new indexes are created or a great deal of data in inserted/deleted/updated, it is a good practice to update the database statistics. If many schedules and/or large schedules are created, the skd tables row counts will have significant changes before and after. Collect the skd tables statistics again (for example the skdactivity table alone might change from almost 0 rows to potentially thousands of rows on new schedule creation). Statistics can be run on just the skd tables or the whole Maximo schema. Note: Refer to Chapter 5 of the Best Practices for System Performance guide referenced on prior chart. 20

21 System Environment Environment can play a key role in the performance of Maximo in general and this is especially true for Scheduler due to the amount of data being manipulated on the server and then sent back and forth to the client. The client does much of the data handling in the applet Therefore, its specs (i.e. memory) will affect performance Assign memory to the java plug-in of 1024 Please follow the Best Practices for System Performance found on this link: mmunityuuid=a9ba1efe-b a181d6155e3a#fullpagewidgetid=w5f281fe58c09_49c7_9fa4_e094f86b7e98&file=c51d5 f5b-dea a81f-d5213fc10063 The IBM Performance Analysis Suite can be used to check for the compliance of the system environment for compliance to the best practice. The tool is available from the following url: mmunityuuid=28cb6d68-ab f9-5538e654a5ff 21

22 Additional Actions to Improve Performance Block Tasks Tasks within a Work Order count as a work order items in Scheduler. If you have tasks that do not require resources to be scheduled, they can be blocked. The Include Tasks in Schedule flag is available at the work order level and at the task level. Leverage the flag if there are some tasks that need scheduling and some that do not. The blocks can be set up in Job Plans and will be copied to all generated work orders as well. Use Subsets of Work Schedules with a large number of work orders can be broken up into smaller subset schedules that are more manageable for the user as well as the application. These subset schedules can be created at a supervisor level or work type level for example. No matter how the work is divided up, an important recommendation is to try and keep work orders and resources in separate schedules (to minimize record contention by multiple planners). Limit your Calendar Ranges The ability to limit the calendar range to a manageable set of records is expected to be added as a Scheduler feature in and above. Until then please follow the guidance in the Support Technote at 22

23 Benchmark Performance 23 Manipulating Data within Gantt: These actions are rapid and scroll smoothly. The performance is constant even as the number of work orders increase Save Move rows Drag and Drop Opening dialogs or Go To other applications Hyperlinks and Actions: These have slightly increased timings but remain responsive as the number of Work Orders increase above 2000 Return from another applications Calculations for Work Cost and Labor Hours Actions To/From Database: These actions do not occur often and show incremental increases to response times when the number of Work Orders increase above 500 Open or return to Gantt Direct changes to selected work orders (includes refresh) Commits (includes refresh) Refresh Time Open or Return, Commit, Refresh, Direct WO Change Save, Move, Drag and Drop, Open Dialogs Volume Return from Apps, Calculations Note: Benchmark information shows lab performance when best practices and latest IFIX are applied to the system. Graph shows relative changes in performance as volume increases.

24 Benchmarks The previous slides outline factors that contribute to customer performance. To provide guidance of performance when these actions are taken, reference benchmark information has been generated. Performance information is being provided for the groupings of transactions previously listed Ranges are used due to account for differences in the transactions Example: Within Actions To/From Database, Return to Gantt may represent low end of range and Open Gantt may represent high end of range. Objective is to help in planning and setting expectations versus providing an expectation for each individual transaction. Benchmarks represent performance when referenced IFIXes have been applied. The benchmarks provide a reference for the size of schedule normally associated with heavy daily or standard weekly scheduling scenarios. Benchmark for a weekly scheduler use case of 100 to 200 work orders Manipulating Data within Gantt 0.1 to 1.5 seconds Smooth scrolling for the interactions Hyperlinks and Actions 1 to 2.5 seconds Actions To/From Database 2 to 8 seconds 24 Benchmark for a weekly scheduler use case of 500 work orders Manipulating Data within Gantt 0.1 to 1.5 seconds Smooth scrolling for the interactions Hyperlinks and Actions 1 to 2.5 seconds Actions To/From Database 5 to 12 seconds For example: Range includes 5 seconds to return from Gantt, 10 seconds to open/load Gantt, and 12 seconds to modify or change rows of data.

25 Benchmarks For heavier volume scheduling or for use cases like the monthly or yearly forecasting, higher volumes of Work Orders or PMs along with longer timeframes will increase the size of the schedule. Manipulating Data within Gantt is barely affected by the increase in size Hyperlinks and Actions is affected slightly by the increase in size Actions To/From Database will increase by some factor since they are volume-sensitive Benchmark for a monthly or yearly forecast use case of 1000 work orders Manipulating Data within Gantt 0.1 to 1.5 seconds Smooth scrolling for the interactions. Hyperlinks and Actions 0.5 to 2.5 seconds Actions To/From Database 7 to 14 seconds For each increment of 1000 WO s, benchmark results change accordingly Manipulating Data within Gantt no significant increase Smooth scrolling for the interactions Hyperlinks and Actions increased 1 to 4 seconds Actions To/From Database increased 4 to 7 seconds 25 These increments are expected up through at least 5000 Work Orders via our internal measurements. We also expect these to continue through even larger numbers of Work Orders, though factors like DB tuning and other workload on a system will affect these larger more analytic forecasting scenarios.

26 Recommended IFIX Levels Benchmark results were generated using a minimum IFIX level For optimal performance, we recommend moving to this minimum IFIX level The minimum IFIX level and the availability date follows: 7503/Scheduler ** IF034 Available May 22, /Scheduler ** IF014 Available May 22, /Scheduler ** IF008 Available May 16, /Scheduler ** IF001 Anticipated June 20,

27 Where to Check IFix Versions It is imperative to be on the latest IFIX to take advantage of the many performance improvements. Before a performance PMR is created for lab investigation, please be certain that you re current by finding your version and IFIX level at IBM Support Fix Central at Select your product configuration, and locate the latest fix pack, e.g. 27

28 Back Up

29 Showing Work Information and Common Operations Scheduler View Save Refresh Commit Action Interact Hyperlink 29

30 Common Query Pattern Example 1 DB2 Example 1: Siteid = (select defsite from maxuser where userid = :user) and (woclass = 'WORKORDER' or woclass 'ACTIVITY') and historyflag = 0 and istask = 0 and status in ('APPR','COMP','WPLN','WCOND','WDOC','WMATL','WSCH','SCHD','INPRG') and (targstartdate <= (current timestamp + 7 days) and targstartdate >= (current timestamp)) The shorter version of the query will be: Siteid = (select defsite from maxuser where userid = :user) and status!= WAPPR and (targstartdate <= (current timestamp + 7 days) and targstartdate >= (current timestamp)) Example 2-6 and 9: no difference from Oracle 30

31 Common Query Patterns Examples 7 & 8 DB2 Example 7: ((woclass = 'WORKORDER' or woclass = 'ACTIVITY') and siteid = (select defsite from maxuser where userid = :user ) and historyflag = 0 and istask = 0 and status in ('APPR','COMP','WPLAN','WMATL','WSCH','INPRG') (targstartdate >= (current timestamp - 45 days) and targstartdate <= (current timestamp + 45 days)) The shorter version of the query will be: siteid = SITE1 and status in ('APPR','COMP','WPLAN','WMATL','WSCH','INPRG') and targstartdate >= (current timestamp - 45 days) and targstartdate <= (current timestamp + 45 days)) Example 8: status in ('WSCH') and (woclass = 'WORKORDER' or woclass = 'ACTIVITY') and worktype in ('A','B','C','D') and historyflag = 0 and istask = 0 and (siteid = 'SITE1') and (maintshop ='SHOP1') and trunc(targstartdate) between trunc(current timestamp) and trunc(current timestamp+14 days) The shorter version of the query will be: status in ('WSCH') and worktype in ('A','B','C','D') and (siteid = 'SITE1') and (maintshop ='SHOP1') and trunc(targstartdate) between trunc(current timestamp) and trunc(current timestamp+14 days) 31

32 IBM Corporation