Performance¶
A well performing solution is an important part of element of delivering a great experience and productivity for your users and your business.
This page provides a summarized overview of useful guidance and tips for getting the best performance from IFS Cloud. For best performance it is important to:
- Consider the performance impact of tailoring such as configurations, customizations, and extensions on the outside. Also consider performance related system parameters.
- Understand good practices that can be employed by end users for better performance.
- Know how to analyze performance to find ways to improve.
- For customers running the Remote deployment model, make sure the environment itself is set up and operated in a way for good performance.
Performance aspects of IFS Cloud¶
For an IFS Cloud solution there are two aspects of performance that are important to consider:
- Interaction response time This is the time a single user has to wait for the application to respond to an interaction such as navigating to a page, searching for information, saving updates, opening up a dialog.
- Resource load This is the total load placed on the application "server side" resources (database, services in the application tier, underlying storage and IO, ...) as a result of the interactions of all users, load from integrations, background jobs running etc.
The interaction response time is affected by the resource load (higher resource load results in slower interaction response time), network performance (bandwidth and latency between the user and the application), and device performance (speed of the device the user is using to access IFS Cloud).
Please note that IFS Cloud will in some situations limit the resources that can be consumed by an single user interaction in order to prevent excessive resource load and thus negatively impacting the interaction response time of other users.
Tailoring¶
When tailoring a solution please be aware that all tailoring's might impact performance to make things slower, as well as faster.
Configuring¶
In general configurations where you add something (custom attributes, additional automation, more content on lobby pages) will result in some performance overhead. In the same way configurations where you remove something (remove elements from lobby pages, hide things in the user interface) often result in improved performance.
Here are a few things that are good to be aware of and consider when configuring your IFS Cloud solution.
- Adding custom attributes to entities decreases performance in those pages, reports, and APIs where the custom attributes are referenced/used (but not in other pages where they are not used). For regular custom attributes persisting a data value the overhead is small, but for custom attributes that reference or calculate values the overhead can potentially be large. Adding custom attributes does not affect performance of the core business logic.
- Using Workflows to add business process automation can affect performance. While it is likely that the steps automated in a workflow would be done at some point anyway (e.g. manually by another user) so the total resource load over time would be the same, running synchronous workflows will increase the interaction response time. Therefore unless a synchronous workflow is required to support the automation need, make it a habit to use asynchronous flows.
- Adding or removing content to Lobby pages can have a significant impact on performance. By removing content (elements) not relevant to your organization or users the load time for Lobby pages improves and overall resource load decreases. In the same way adding additional lobby elements, whether standard ones provided with IFS Cloud or ones you design yourself, add resource load and decreases response times.
- For configurations such as Lobby Data Sources and Quick Reports that allow SQL to be used, the performance guidance for SQL apply.
- For configurations such as Event Actions that allow PLSQL to be used, the performance guidance for PLSQL available apply.
Customizing¶
When developing a customization, all performance guidance available in the Developer's Guide apply.
- Development - SQL
- Development - PLSQL
- Development - Upgrade scripts
- Development - Cloud Web pages and projections
Settings and Configuration Parameters¶
There are a few system parameters that have a direct performance impact:
- Search dialog match case default This parameter determines whether searches done by end users, by default, should be case sensitive (faster) or now (slower). For better performance leave this parameter to its default value which is ON.
End user good practices¶
End users have multiple options available to them that can result in improved performance and interaction response times.
- Consider how a page is started when opened from the navigator. All pages have a default behavior. Many pages like "My Expenses" will just show the data (in that case expenses), whereas others like "Customer Order Lines Analysis" will start by presenting the search panel, assuming that users commonly want to do a search anyway. Individual users can override this default behavior in the search settings to either start by showing available data, by making a new search, or run a previously saved search. When a user commonly wants to see a particular search set of data in a page it will be faster to set that page to start by running that saved search, than to first start showing all data and then run the search when user selects it. Or if the user typically makes a new search every time, set New Search as the startup behavior.
- When searching users will in general find it convenient that the data is refreshed immediately when they change any of the filter fields. However in situations where users commonly need to enter multiple filter values (e.g. a filter on company, and on accounting year, and on accounting period, and on code part, and...) it is more efficient to defer actually refreshing the data until all filter values have been entered. Users can select whether to run the search immediately when a filer value changes, or only when the user explicitly presses the Search button, in the search settings. Just like with the page startup behavior some of the pages in IFS Cloud already have the "only when Search button is pressed" option set by default.
- Hide columns in lists that you are not using. When an end user hides columns in the lists, IFS Cloud will no longer retrieve that data which means that data loads faster (less data to retrieve, transfer over the network etc.). If you leave the columns visible but outside the horizontal scroll range, the data will still be retrieved so it is more efficient to hide columns rather than just "moving them out of view".
Analyzing performance¶
In the course of finding performance problem it can be good to understand from where they can arise, as:
- Lack of resource
- Over-use of resources
- Configuration leading to not be able to use resource
- Application architecture to not be able to use resource
To be able to benefit from monitoring in general it is good to have knowledge about how the actual usage of the system is in terms of users/integrations at the time for current monitoring, it is also good to understand the baseline of the user load as normal so we know how it looks when system is performing well. This relationship can later be used to understand peak usage.
An overall health control can be checked by Cloud Web Application Monitoring Console it provides the means to find if there are any thresholds of measurements that has been breached. Specifically to check index, and state of the index there is the "Oracle Index Management" where you will find info on index state.
Tools to use in case of performance problems in Cloud Web for finding specific root cause would be to use a Browser debugger as for example Chrome DevTools which will give insight on where the most time is spent on a page or task in Cloud Web client. Also there is the Cloud Web Debug with "Debug console" and "Log Window" which can give even further information of actual SQL statement's and tracing on database side.
For finding root causes of performance issues it is vital to monitor all components in the system, from OS to applications information, from client to backbone. Make use of all monitoring you can get your hands at. If there are error-messages please read the error messages and believe them, usually they are right
On the database there are powerful Oracle Database tools for monitoring, Oracle Enterprise Manager (OEM) and Oracle Workload Repository (AWR), these will however require additional licenses on Oracle. But there are also some free tools from Oracle that can be used on different scenarios example of tools would be SQL trace, trcsess, tkprof, Trace Analyzer. And there is also a bunch of third party tools for Oracle monitoring, both free and commercials.
Environment setup and operations¶
For Remote deployment model make sure the environment is appropriately sized, referencing the sizing guides for IFS Cloud. This applies in particular to sizing of the database as well as the pods, replicas, and notes in the Kubernetes cluster (there is configuration help for sizing of pods and replicas/node configuration calculator). If you are running older end user devices (laptops, mobiles etc.) then remember to check against supported platforms as well as minimum requirements for end user devices.
On servers in the environment it is important to have the latest appropriate firmware's recommended by the hardware vendor, this will include enhancements for functionality, performance as well as security. For configuration of hardware there could be settings that can effect performance as settings for CPU speed, threading, NUMA and memory. If possible try to validate any configuration changes to correspond to wanted outcome, especially for threading and NUMA. For the OS configuration mainly for the Oracle database follow Oracle's installation guidelines specific to the OS and hardware the database is installed on. The swap space need to be configured accordingly to OS vendor recommendation, usually in relationship to installed memory. In some high request intense systems there could be need to tweak the TCPIP configurations, this is valid on both UNIX and Windows.
Installation of IFS Cloud should be done with a minimum of resources calculated in sizing guide as database SGA memory and middle-tier replicas, and also using the provided templates and helm chart's. Make sure to configure administration jobs to cater for up to date Oracle statistics and rebuilding skewed indexes, monitoring the output from the jobs is needed occasionally. It is also advisable to manage data for archiving to reduce the amount of resources needed.