2084003 - Compensation & Variable Pay - Optimize Performance issues, Slow Page Loading & delays in Creating Worksheets

• Compensation performance issues
• Variable Pay performance issues
• Compensation worksheets are slow to load
• Takes long time to create worksheets
• Takes long time to create statements
• What is maximum page size for a compensation plan?
• Why can we only display a maximum of 50 people on the compensation plan?
• Can we limit the number of people listed on the compensation plan to less than 50?
• Setting comp-page-size attribute
• Executive review loading slowly
• Updates applied to Employee Central taking a long time to process.

**Image/data in this KBA is from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental**

• SAP SucessFactors Compensation
• SAP SucessFactors Variable Pay

• There are a number of reasons that you may see slower performance from the compensation and varpay module.
• The following information provides information on how you can improve overall performance when using the compensation module.
• As you review the list please also keep in mind each factor has an impact on performance, so while no one factor described below may by itself be concerning, a combination of factors will often result in a worksheet, program, or report that planners find unacceptably slow.

For example

• A very basic worksheet set at < 20 people per page is loading in 0-5 seconds.
• You allow max page size of 50. This adds 5 seconds overhead on page loading.
• You add 2 very large custom fields and picklists, each adding 10 seconds overhead.
• You have extremely complex eligibility rules coupled with complex RBP rules adding another 10 seconds overhead.
• The total result with these in a worst case scenario, before we even factor in PM ratings, Goals, and other real-time data calculation needs, results in the page taking 40+ seconds to load, or to go from page to page.
• Simply adopting best practices and simplifying rules and data demands can bring the same page back in-line to deliver the needed results within 10-20 seconds.
• If by nature the program is complex, and not easy to simplify, it is important for you to educate planners so they understand the complexities of the program which results in slower real-time results than what they might be expecting, thinking this is "just a webpage".

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 must not be set to clear cache after closing a session.
• The first time load of a page can be substantially longer than normal. In one example for a large program it could take 30-60 seconds on the initial visit to build the page and cache your compensation page data.
• When you re-visit this page, the load time will be dramatically reduced, often to 5-10 seconds (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 compensation pages, 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.

Page Size Option

• One restriction we have in place for compensation to improve performance is the page size.
• You will note that the maximum you can set the page size to is 50 members per page.

Why do we have the option Maximum Page Size (up to 50, only applicable to compensation forms) on your compensation template?

• The compensation and VarPay worksheets deliver real-time analytics each time you view the page for the first time, and navigate between pages and tabs. There is no cached data on the first visit, as the product is designed to always deliver real-time data. This approach can have a negative impact on page loads and performance, but has the benefit that your planners and managers always seeing current data in worksheets, that reflect any changes that have been made in goal plans, performance forms, and user data imports.
• We therefore recommend that users change this setting to 10 or 20 per page if the page load is too long when set at 50. The performance increase will be seen immediately. In general (as explained further below) a worksheet set to display just 20 users per page will load up to twice as fast as one set for 50 people.

• The administrator can limit the total number of people listed per page load from Admin Tools > Form Template Administration > Form Templates > (Your template name) Scroll down and select the setting for Maximum Page Size. [Maximum Page Size (up to 50, only applicable to compensation forms):] The maximum is 50, but you could limit it to 20 to help manage performance.

• A configuration change can also be made to the xml to the default page size for each plan.
  <comp-page-size>50</comp-page-size>. This can be requested via customer support.

Executive Review

• The executive review by nature rolls up large volumes of data, and can therefore be a specific feature that takes longer than other features to calculate and display real-time data. There are some options available to you to improve performance if the specific area of slowness is the Executive Review, and not the worksheets in general. Please refer to: 2084738 - Compensation: Executive Review - Do not automatically retrieve compensation data
• Another factor of rexecutive review when used with Variable Pay is to ensure the program has enablePerformanceOptimization flag within the program. The optimization flag enablePerformanceOptimization is automatically added to new programs, but we have noted old programs may need this added. See SAP Note: 2077418 

Eligibility Rules

• If your program has never performed with speed, it maybe due to factors such as excessive eligibility rules. Logically, for every rule you create, additional time is required evaluate, calculate and apply that rule for every person on the worksheet. That is multiplied for every rule in your program. Typical programs have a few to at most 100 rules, and if this is the case with your program, it is unlikely to be the culprit. The exception may be some very complex calculations you have with various rules. However, if you have many hundreds of rules, then these are likely impacting performance loading.

• Tip: If you have hundreds of rules try this. Remove most of the rules and retest a new form to confirm if this eliminates slowness issues. If it does, consider if you can consolidate or simplify how many rules your program is using. Importing data 

Employee Central Integrations

• If your program is connected to Employee Central, then updates to Employee Central that need to also update your Compensation or VarPay 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 or twice a day.
• In general a compensation/VP program connected to EC 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. 
• For EC-integrated templates it is not recommended to exceed 100 employees on a single form as a high number of employees on a single EC integrated form can have a direct imapct on the performance of the system. Executive review should be considered as the alternative to enter recommendations for large population son the same screen.

Lookups & Pay Guidelines

• Lookups and Pay Guidelines should be evaluated to determine size.  Lookup tables should be no larger than 2K for each table to prevent latency issues. 
• The general rule is to keep these files/data sets as small as possible whenever you can simplify. For example if you had 5,000 pay guidelines for 10 regions that are essentially the same, it is better to enter only the 5000 unique pay guidelines, and not 50,000 records that repeat all the information. Our systems don't have any hard limit to how many you use, but logically increasing complexity will always result in a performance trade-off. Our recommended limit for lookups are about 2000 records. We test the system performance on this benchmark. You can enter far more than this but again, increasing complexity will result in performance degradation.

Custom Filters

• On occasion we have seen clients using overly exhaustive data in custom fields. The "normal" expectation for fields on a compensation worksheet are for standard fields, that contain minimal unique values (1-100). Typically you are using these in a drop down list that you want planners to select from.

• As each field has to be evaluated per person on the worksheet, even just 100, can multiply quickly to 5000  values we now need to display if just 50 people are on the worksheet. If you have custom fields that have much larger unique values, say 1000 in the list, then that value now quickly explodes to 50,000 values to load for this page for just this 1 single field before any other loading is done.

• Review all the fields, especially custom fields on your worksheet. If you have any that are referencing large lists of data that you are attempting to show via dropdown lists, remove this field and see if this immediately improves performance.

Complex Formulas

• Formulas are more and more popular these days within compensation programs, 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 dozens 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 compensation and Variable Pay programs 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 compensation program since all these areas are typically feeding your program. 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.

Typical Functionality of Page Loads

• It is important to note that as a real-time web application (as opposed to a regular webpage) your compensation plans perform live calculations each time the page loads, and as you move from one page to another (in addition to the data we can cache as explained above). For each person listed in the form the number of calculations increases in a linear fashion, so the more people, the longer it will take to complete all calculations and load the page.
• Keep in mind, to perform a single calculation for a single person you may have many modules integrated with your compensation form. For example, your merit guidelines may be driven by a performance score. This performance score comes from the actual performance form of the user, so the system needs to go and open that form for that user in the background to make sure the calculations use the current performance rating (since often PM forms can be still in-progress). In turn, the overall rating on the performance form may be calculated from other modules, for example a goal plan. So before budgets can be calculated, the worksheet first needs to grab the current overall rating from the PM form. And before it can even do that, the PM form nay need to open the connected goal plan to make sure that the overall rating is calculated using the most current goal data for the individual. Only once that has been done can the goal plan update the PM form and the PM form in turn update the rating on the compensation form, at which point the compensation form can now make its calculations for budgets, merit and other values for that one person. This process is then repeated for the next person and so on.

• The above scenario outlines a typical process, but you may have even more complex dynamics involved than this, which is why a compensation form is typically slower to display than most other pages in the SuccessFactors Application. The trade-off for performance is that the managers can have confidence that they are always seeing accurate up-to-date data in the compensation plan, even though they may not personally have any insight into other modules that are feeding your compensation cycle.
• All of this is done in milliseconds, so the system performs extremely fast for each person, but even assuming that was 1 second or less per person, if you had 50 people on the compensation form, that could take 20 seconds or longer to load, which can seem a long delay for a 'web page'. It is helpful to remind managers that this is not a web page, but a web based application that is performing real time analytics across many modules to deliver up the compensation plan.

• This time is usually only relative to how many records are being displayed per page. If you had 500 people on the plan, but only viewing 10 people, the time to load is based on the 10 records, not the fact there are 500 in total, but total size of program per planner worksheet should not be overlooked.

• We recommend that planners leave the setting at 10 people per page when they see unacceptable delays loading the page, and further optimization of your program as described above cannot be done.

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 worksheets, 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.

Browser Extensions

Under certain circumstances some browser addons could negatively impact performance and usability while working with SuccessFactors, therefore if you find a performance issue, as part of the initial troubleshooting please try reproducing it deactivating any browser plugin. Also trying to reproduce the issue in browser incognito mode could help. Please note that these kind of browser plugins and addons are third party software which falls outside of the scope of SuccessFactors support

Takes Long Time to Create Worksheets (Launch forms)

• Please keep in mind that for all of the variables discussed above, they also will apply at time of creation, as naturally as the system physically builds every single form, it also needs to perform every action, calculation, data load, etc for that form to be created, and then moves on to the next form. So while creating 500 forms may be almost immediately, creating 5000 could take a few hours, and 50,000 may take considerable time over night. Still, as every form can be different 50,000 very simple worksheets that are very light on data anlookups etc could generate faster than 5,000 forms that have great complexity, lookups, calculations, and heavy on data. Typically there is nothing support can do to speed up launching once it has started. DO NOT cancel the job, as unless you have removed or changed your configuration, it is very likely to be just as slow when you restart, and therefore all you will do is delay the creation even further.
• Please go to the job monitor in admin tools, and confirm that they job is still running. If it has not failed and still running, albeit slowly, please give it time to complete.
• It is better to troubleshoot slow programs later when you do not have a deadline to launch, as changes to your programs will probably take some time to identify, reconfigure, and test before you can incorporate those improvements into your next cycle.
• Only open a support ticket when your program fails to launch, or when you want to review your program setup to determine what performance enhancements you can make as outlined in this article.

Improvements to Mass Update Jobs

• Starting 1H 2023, large jobs for Compensation and Total Compensation templates are now split into smaller sub jobs when the feature Actions for all plans  Company Settings  Manage Company Settings  Enable Sub Jobs for Mass Update Optimization (Compensation and Total Compensation) is enabled. 
• In case, there are jobs scheduled to run concurrently, the second job fails and a notification is sent to the job owner. This validation and prevention of mass job creation concurrently is available on both User Interface and Provisioning.

Takes Long Time to Create Statements 

• Here again, all the information above also applies to the creation of statements.
• Please go to the job monitor in admin tools, and confirm that they job is still running. If it has not failed and still running, albeit slowly, please give it time to complete.
• It is better to troubleshoot slow programs later when you do not have a deadline to launch, as changes to your programs will probably take some time to identify, reconfigure, and test before you can incorporate those improvements into your next cycle.

compensation slow, performance issues, compensation peformance, worksheets slow, worksheets not opening, opening, slowness, form launch delays, best practics , KBA , sf compensation , sf comp admin , LOD-SF-CMP , Compensation Management , How To