2488984 - Top 10 Reasons the SuccessFactors Application is Running Slow

• System Performance issues
• Web pages are slow to load
• Takes long time to create worksheets, forms, statements etc.
• What is maximum page size?
• What can cause pages slow to load?
• Disconnected/kicked out/logged out of the application while working
• Experiencing severe slowness in my application
• Is something happening in my datacenter?
• SuccessFactors System Unavailable errors
• Slow Reports and Other Transactions Taking Too Long

SAP SuccessFactors HXM Suite

Introduction

• There are a number of reasons there may be slower performance within the system, webpages slow to load, and transactions taking too long to complete
• The following information provides information on how you can improve overall performance when using the SuccessFactors Suite
• As you review the list, 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
• A common mistake is to presume slowness must be due to the SuccessFactors Application itself, and while that is always a possibility, it is most often not the cause
• The most common causes are generated by users of the system adding data, changing settings, permissions, adding invalid configurations etc, or performing functions in such a way that the normal and optimal operation of the system is impacted
• Before concluding the issue must be something SAP has to correct, review the following article and consider if you or any administrator, partner or person responsible for maintaining the system might have recently introduced some factors that are now causing slowness 
• When slowness is due to factors on the SAP side, this typically impacts large groups of customers, and SAP is often the first to be aware of such issues, and is likely to be working towards a fix before most users or customers are even aware of the impact
• If you are the only customer affected, that in itself is often a clue it is something unique to your settings, data, implementation or configuration
• If you feel the issue is most likely on the SAP side, please see KB article 2112343, otherwise review the information below

Common Example of Slowness and it's Various Causes

• A very basic page that reports on a small set of people, and is not integrated with other modules, or required to pull in live data to display is loading in 0-5 seconds.
• You have a more complex page trying to display data on hundreds of people. 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 before we even factor 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, picklists, 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 administrators so they understand the complexities of the program (versus a static webpage).
• Complex pages will logically result in slower real-time results than what might be expected if people think this is a static webpage that should load immediately.
• Educating admins and end-users about your most complex pages and programs can often eliminate calls to your support desk 

Product Specific Knowledge Base Articles

• Please see a list of related articles linked at the bottom of this article
• These can provide in-depth information on causes of slowness within specific product areas not covered in this article

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 

Picklists

• A very common cause of slowness are picklists. Picklists are the fields on your page that have a dropdown selectable list of values the user can select. 
• It is common for your instance to use many picklist fields, and it is normal for some lists to contain very large lists of values (up to 1000 values would not be unusual). However keep in mind, picklists not only become hard for a user to use the more options they need to scroll through to find a choice, often as these values are coming from live data (not a static list) such as division, department, location etc.. the system has to evaluate and load this list for every occurrence it is on the page. A poor practice is to have many fields with extremely large value lists. Avoid such implementation configurations. 
• Avoid having large numbers of custom picklists on any 1 page or program.
• Delete any unused picklists in your system using the DELETE function. 
• Try a program or page that does not contain the large or complex picklists to compare load time against. 

Page Size

• Is the slowness happening on 1 page or every page you visit?
• If some pages like a basic employee profile page is fast to load whereas other more data-rich pages are slow, it is likely the integrations and real-time-data factors causing the slowness. 
• Can you filter or restrict the data set to see if this speeds it up?
• Are you loading more data than you really need to? For example, rather than showing thousands of records, could you reduce the dataset and compare results?
• What is the make-up of the page? Is it linking to many other modules to get it's data? is it overly complex where maybe you could simplify it? 

Rules Engine

• If your program has never performed with speed, it maybe due to factors such as excessive rules defined within your rules engine
• Logically, for every rule you create, additional time is required evaluate, calculate and apply that rule for every person on the page
• This is multiplied for every rule in your program and typical programs have a few to at most 100 rules
• 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, 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. Even better practice is to test your program as you are building it, not once its finished. this way you will have results to show that early on the page was fast, and likely start to notice when the page/program gets slower as you add further complexities to it

Employee Central Integrations

• If your program is connected to Employee Central, then updates to Employee Central that need to also update your page may trigger data refreshes to determine the most current values, and these will add time
• Customers should not try to trigger these refreshes too frequently, such as hourly, as it is not unusual for a program to take longer than 1 hour to refresh
• The refresh is not even completed before the next job starts, which in turn will cause a system slowdown
• It's recommended not to refresh your programs any more than once or twice a day 

Custom Filters

• On occasion we have seen clients using overly exhaustive data in custom fields. Review your custom fields and determine if they are complex or not. Custom fields often use dynamic picklists or calculations.
• As each customer filter field has to be evaluated per person or record on the page, it can quickly multiply to tens of thousands of values. 
• 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 improves performance. 

Complex Formulas

• Formulas are more and more popular these days within 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.
• A good question for administrators is when did the issue start and has anyone recently added new permissions to the system? Changed data via an import that may now be impacting permissions? Had a config change done that is now impacting permissions?
• Tip: Many times an admin will forget to ask everyone within the company that has admin permissions, assuming no one has made any changes, only to find out after much time and effort working with support that indeed another admin in another location, or supporting a different module had indeed performed a permission change or imported master data, not realizing the impact their actions was having on other parts of the product. 

Immediately After New Data Loaded

• A good question for administrators 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
• Keep in mind 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
• 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 

Lookups

• Does your program include lookup tables? 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

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 

Takes Long Time to Create Forms/Records ('Forms' could be anything you are creating)

• Please keep in mind 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 lookups 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 

 KB article 2112343 - System Slowness: What to do if the SuccessFactors Application has Performance Issues

SF, success factors, PLT, platform, EC, RCM, LMS, SCM, PMGM, PM, GM, MTR, CMP, poor performance , KBA , LOD-SF-PLT , Platform Foundational Capabilities , LOD-SF-EC , Employee Central , LOD-SF-INT , Integrations , LOD-SF-ANA , Analytics & Reporting (Ad Hoc, YouCalc, ORD) , LOD-SF-EP , People Profile (Employee Profile / PP3) , LOD-SF-OBD , Onboarding , LOD-SF-SCM , Succession Management , LOD-SF-PM , Performance Management , LOD-SF-CAL , Calibration Module , LOD-SF-CMP , Compensation Management , LOD-SF-GM , Goal Management , LOD-SF-MTR , 360 Multi Rater , Problem