Skip to content

IFS Lobby Performance Guideline

IFS Lobby is a powerful visualization that can show information from many different tables in a single page. This is different from ordinary overview or detail windows which are based on one or a few hard-coded tables. IFS Lobby defines pages, elements, and data sources. A page contains one or more elements. An element is connected to exactly one data source and one data source can be reused between several elements.

This describes performance aspects for design of data sources, elements, and pages.

Knowing your users

IFS Lobby is designed to present operational data rather than high-level analytical data (except for Lobby data source and element types explicitly designed for anlytical data). IFS Lobby is meant to provide a focused (on and individual, role, or process) perspective and is not intended for large volume of data spanning entire organizations.

From a performance perspective there are two key questions that need to be answered.

  1. How many users are running the lobby?
  2. How often is a lobby being refreshed for one user? Refresh occur either on navigation, explicit refresh-button clicks or automatically defined in the page.

Knowing your data

The IFS Lobby elements mostly perform SQL queries towards IFS Cloud database. Some characteristics of these queries are:

  1. Query result set is small. Result size is often just one row or up to max 100 rows.
  2. Aggregate functions are commonly used.
  3. The data set traversed in the tables are often significantly larger than the result set.

General IFS Lobby Performance Discussion

Database queries in a well-tuned, balanced, IFS Cloud are generally CPU-bound. This means that the query execution time is dependent on number of cores (and their speed) on the database server.

A mid-high-end database server can have 32 cores, meaning that it can optimally serve 32 parallel requests. More than 32 parallel requests will force server to preempt request executing switching, leading to decreased throughput and longer response times. These cores are used for many different things, serving ordinary forms, background jobs, reports, integrations etc.

Consider a theoretical scenario with an IFS Lobby with 20 elements and each element has a response time for 2 seconds and using a default configuration of 5 parallel requests:

  • IFS Lobby will load completely in (20*2)/5 seconds = 8 seconds.
  • 5 cores will be completely occupied in 8 seconds for one user.
  • Database will be almost saturated when more than 6 users are running the IFS Lobby page at the same time.

Another way of thinking is to discuss the number of elements per IFS Lobby. Let's assume we split the above example into two pages; that is we have two IFS Lobby pages with ten elements each. This does not change how many parallel users that will saturate the database but it will reduce the risk of users running those questions in parallel. You can also consider providing a little less information up front in the Lobby and instead encouraging users to nagivate to another page for more details.

Lobby pages should provide a quick at-a-glance overview for the users. A pages where elements take a long time to load does not provide the a good experience. To provide a good experience and also to limit the load impact of individual lobby pages, IFS Cloud will automatically time out Lobby elements connected to SQL data sources after a few seconds, continuing to run the data source longer only when the user explicitly asks to do so. This automatic time out helps assure that other lobby elements and users are not negatively impacted of individual elements taking a long time to return.

Design of IFS Lobby Elements (and Data sources)

Due to IFS Lobby performance scalability, elements should return results quickly. Depending on how an element is used in a page and amount of data in tables, it might be acceptable with longer response times in certain situations.

From a performance perspective when defining an element it is important to determine the size (number of rows) of the main (or driving) table(s) in the data source behind the element.

The driving table is normally determined from:

  1. The table that has the most selective index used from element parameters.
  2. The table in the from-clause if only table exists.
  3. The largest table in the from-clause if tables are joined and no indexes can be used.
  4. All driving tables summarized if used in UNION/MINUS/INTERSECT clauses.

The size of the driving table is normally linear to the element response time.

Below is a green-to-red categorization of elements. Avoid developing category Red elements.

<1s 1-2s 2-5s >5s

IFS Lobby SQL Data Source Performance guidelines

SQL Data sources creates and runs one single SQL statement for viewing in IFS Lobby element. It is important all SQL statements defined in SQL Data Sources has been examined and performance tuned. In order to tune SQL data sources, the commonly available SQL tuning guidelines are also applicable on IFS Lobby SQL data sources.

  • PL/SQL calls in SQL statements has a significant negative impact on SQL performance. This is regardless if the PL/SQL functions does almost nothing, just context switch from SQL to PL/SQL is expensive. The more context switches, the slower performance; therefore is PL/SQL calls in WHERE clause often much worse than PL/SQL calls in SELECT clause.
  • IFS Lobby data source parameters that can be mapped to a selective index can increase query performance.
  • Massive SQL statements with unions, deep joins, sub queries etc can be slow. Such statements are often BI-style statements and could be handled with functionality such as Oracle Materialized Views.
  • The performance guidelines and tips described in Developers Guide for writing business logic also apply when defining SQL Data Sources for Lobby

Generally, the more work is needed to retrieve data, e.g. traversing large tables, accessing tables, large sort and aggregations, doing lots of PL/SQL calls, the longer time and more resources the work will use. Where any of these areas can be reduced, less resources are used, making resources available for other user, and better response times.

Designing IFS Lobby Pages

When designing an IFS Lobby page, it's often easy to add many elements thinking that more is better. However more is not always better, in many cases it's better to have a clear purpose for the IFS Lobby page and make the solution fit for that purpose. Include what's necessary but remember that many elements which fetch data from IFS Applications will put more pressure on the system.

An IFS Lobby page should be completely filled within 10 seconds when all elements are filled in sequence one after the other

When a page parameter is used as a data filter, avoid using wildcards such as '%' if possible. Wildcards can fetch unnecessary amounts of data but by explicitly setting the page parameter you can avoid unnecessary amounts of data fetched.


Know your users and the data presented in the IFS Lobby page. IFS Lobby has a scaling factor different from ordinary forms. Tune the element data sources according to SQL guidelines. The number of elements on page can have a significant performance impact, make sure your IFS Lobby page is fit for purpose and remove unnecessary elements from the page. Where page parameters are used as data filters, avoid using wildcards such as '%'.