2399884 - Optimize PM Form Performance - Slow Page Loading - Slowness Creating or Routing Forms- System Performance Issues - Performance Management

• Performance Management Form performance issues
• 360 form performance issues
• Performance forms are slow to load
• Takes long time to create forms
• Mass routing of forms seems slow
• Best practices on managing large groups of forms (20,000 +)

SAP SuccessFactors Performance Management

There can be several causes for this issue, as described in this article.

There are a number of reasons that you may see slower performance when using performance management. The following information provides information on how you can improve overall performance when using the PM module.
As you review the list please also keep in mind that each factor has an impact on performance, so while no one factor described below may by itself be concerning, a combination of factors can result in a large groups of forms or reports being slow.

Note: As long as your forms are still launching, or routing, although very slowly, support will not be able to intervene in the transaction. We cannot cancel or restart, since the root cause is likely the forms itself and restarting would only result in the exact same slow transaction. The speed is often a factor of form design and changing that design is simply impractical for a customer to make once forms are live. Please just monitor your form launch, and routing, and only contact support should the job totally fail. Very large batches of 50,000 forms could take many hours in periods of peak service, and the only option is to let the transactoin complete once it is underway. General server latency issues will self-resolve within a few hours so the best course is to monitor the progress and check back. 

Please consider the following information when building your program. The more best practices you can adopt, and the simpler your program design is, not only helps ensure the best system performance, but by nature, also the best user-experience. A well designed simple program that delivers a user friendly experience will be an important factor in the success of the program, as user adoption increases. 

First Time Loading & Cache

• The SuccessFactors web application is built on web2.0 fundamentals, and as such, relies heavily on browser cache. The first time you visit any page the system will automatically download and cache a lot of information. Your browser therefore should not be set to clear cache after closing a session. The first time load of a page can be substantially longer than normal. When you re-visit this page, the load time will be dramatically reduced (not including additional data as described further below).
• Therefore, one thing to check (or review with your IT) are the browser settings to ensure that browser cache is set not to expire or to be deleted on close of session, as that will have large impacts on not only forms, but the To-Do list and other pages. In addition to the data we can cache, there is also the real-time data to consider as discussed below.

Shared Cloud Service

• If your program contains very large numbers of forms (20,000 +) keep this in mind....
• As a cloud service, keep in mind resources can be shared, so try to pick non-peak times that other business in your same data center might be launching. For example Jan 1st, during peak business hours of your data center locaiont, or having your dates on obvious popular dates such as a quarter end. 
• Remember that testing performance speeds in your test instance does not provide a real world comaprison to the demands that may exist in your production instance that is going to have a heavier demand on resources. 
• If you are launching very small batches of 5000 or less, probably you will see no dealys, or if there is a delay it is only a few hours, so just check back in an hour to see if your transaction has completed. 

Mass/Bulk Form Launching and Routing Tips For More than 20,000 Forms

• Most form launches or mass routes will happen in near real time. For every 5000 forms the transaction time will grow noticeably. There are practical steps to take to reduce latency issues. 
• Have users manually move forms as they finsih a step as opposed to always relying on auto routing all forms at the same time. Rather set a deadline for all users to manually move their forms, and then have an auto-route date set in your route map for a few days later so that the number of forms auto-routed at the exact same time is greatly reduced. 
• Rather than launch all forms at once to the entire company, launch forms to subdivisions or business groups on different days, so that there is never 1 single failure point for the entire company.
• 10 launches to different business groups with 5000 users each, is less error prone than 1 massive launch of 50,000 forms to the entire company, especailly is there is no real business reason they have to be all 1 group. 
• Check the SAP SF maintenance and release calendars to ensure your forms are never set to auto move on a day that the system is offline. Our system will auto-route when back up, but now your forms are all queued with all other customers also now queued for routing. 
• Try to set auro launch or auto route dates to uncommon dates that are unlikely to be peak business times for every one else.

Goal Plan Integration

• Most standard PM forms have at least 1 goal plan section built into them. A goal plan section is an integratoin with the GM module. The system has to actually go and look into the goal plan, evaluate the goal data, before it can populate the data in your PM form's goal section.
• In a typical PM form this should not cause any latency or performance issues. However, if your program contains multiple goal sections, or very large and complex goal sections, this could well be a design issue that can cause performance degredation. 
• Also, make sure goals are using best practices in naming convention and size, not being overly large causing your page sise to be thousands of lines long.

Employee Central Integrations

• If your program is connected to Employee Central, then updates to Employee Central that need to also update your program may trigger an full recalculation of your program. Customers should not try to trigger these refreshes too frequently, such as hourly, as it is not unusal for a program to take longer than 1 hour to refresh. Therefore the refresh is not even completed before the next job starts, which in turn will cause a system slowdown. Our recommendation is not to refresh your programs any more than once a day (unless you have very small numbers less than 10,000).
• In general a program connected to EC that requires real-time dynamic data lookups could cause an additional 25% performance drop to launch, mass route, mass update etc than a non-EC program. This would be in addition to any other factors that can cause performance drops as described in this article. 

Total Performance Form Size

• The more content you include in your performance or 360 forms will increase form creation time, routing time, and viewing time. You don't have to worry about this too much as most companies have pretty standard forms, that are not too long or exhaustive as a best practice since failing to keep it brief puts an unwanted burden on your users who may now not want to invest the time in providing feedback.
• Keep programs to the point, so that it is user friendly. 
• If you make it overly complex, adding hundreds of goals & competencies, or including extremely large goal data etc, this could cause some noticable latency in program use.

Very large Picklists and Form Values

• A common mistake is to create very large picklists that have more than 1000 selectable values. 1 field with 1000 possible options may not cause any noticeable latency, but if this field is repeated multiple times in the form, you now increase the effective size to possibly tens of thousands of values the form now contains, which could result in noticeable latency issues not only for users, but also when creating or routing the forms in bulk.

Custom Filters

• On occasion we have seen clients using overly exhaustive data in custom fields. The "normal" expectation for fields on a form is that they contain minimal unique values (no more than 100). Typically you are using these in a drop down list that you want planners to select from. Asking users to select from more than 100 choices is in itself a poor user experience, but could also add to performance issues. Still, you can add as many values as you like, it is just not a recommended practice. 

• Review all the fields, especially custom fields on your forms. If you have any that are referencing large lists of data that you are attempting to show via dropdown lists, determine if this logic can be simplified to improve performance.

Complex Formulas

• Formulas (often in the goal fields) are more and more popular these days within forms, as it eliminates the need for you to pre-calculate data before entering it into the system. Keep in mind however that there is a direct trade-off between importing data as an absolute value that needs no further calculating versus importing raw data and having the system perform this calculation for you. For very simple calculations such as "If this person belongs in this Department, then result = X", there should not be any performance hit. However, many companies are creating ever more complex nested formulas in their programs which do have a direct performance impact.

• Review all the calculations that make up your program. Is it less than 10 basic formulas? Or do you have a large number of extremely complex nested formulas? Try to keep custom formulas simple, and when possible, import the results to eliminate any need for further calculation.

Role Based Permissions

• Overly complex RBP can have a negative impact on program performance. When your permission roles and groups have simple logic to them, such as "these people belong to this department" or "this person is a manager of these people", then the impacts are likely to be unnoticed.
• However if your company has very large and very complex roles and relationships, then evaluating all of these to determine who can see what BEFORE we load the page, is logically going to increase load times.

Immediately After New Data Loaded

• A good question for administrators of PM or 360 forms is when did the issue start and if any new data has just been loaded?

• This may be right at the start of the cycle, or part way through. Also keep in mind that other administrators for other modules such as employee data, PM data, or Goal data could have performed the data update now impacting your program since all these areas are typically feeding your form. Therefore, before opening a case with support, check with your internal teams to confirm if any data was recently loaded that might explain a sudden change to system performance and behavior.

Random Performance Issues Just Started

• After considering all the above, a final consideration is when your program has otherwise been performing well, and was not problematic at the time of launching forms, and only suddenly degraded in performance. If this has happened and you are confident that no one has inadvertently changed settings or loaded new data, then there may be an unexpected server issue that we need to evaluate. Please open a case with Customer Support who can help analyze your program.
• Our team with the help of engineering can "Profile" the program with your assistance and analyze the slowness to determine if it is being caused by something in your program that needs to be optimized, or if the SuccessFactors servers and calculation engines are not handling data in an optimized way.

optimize, PM form, performance, slowness, settings, slow page, load, loading, creating, issues , KBA , csg_q , LOD-SF-PM-SCH , Form Schedulers and Launches , LOD-SF-PM , Performance Management , LOD-SF-MTR , 360 Multi Rater , LOD-SF-PM-FRM , Forms & Templates , Problem