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.
IFS Lobby is designed to present operational data rather than high-level analytical 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.
The IFS Lobby elements mostly perform SQL queries towards IFS Applications database. Some characteristics of these queries are:
IFS Lobby uses a multi-threaded client implementation where element content is retrieved in background, keeping the UI responsive all the time. This background content retrieval is by default using 5 concurrent workers (5 parallel requests). Actual value is configurable in Ifs.Fnd.Explorer.appsettings
<!-- Number of maximum concurrent server calls from IFS Lobby. Default if not
specified here is 5. -->
<!-- <add key="maxConcurrentLobbyCalls" value="5" /> -->
For each element call there is a timeout set to 60 seconds. If no response has been received by the client after this time the call will be cancelled and the client will show a “no response received interface” for the element in question. This timeout is configurable in Ifs.Fnd.Explorer.appsettings.
<!-- Sets the timeout in milliseconds to wait before the request times out for
server calls from an IFS Lobby element. Default if not specified here is 60000.
For Infinite use -1 -->
<!-- <add key="timeoutLobbyElement" value="60000" /> -->
Database queries in a well-tuned, balanced, IFS Applications 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:
Is lowering the maxConcurrentLobbyCalls (ie making IFS Lobby less greedy) an option?
Consider the same scenario as above but using a default configuration of 2 parallel requests
System will cope with more IFS Lobby users before it gets saturated, but user experience get far worse.
Only use the maxConcurrentLobbyCalls to tune IFS Lobby overall usage ratio compared to other client requests.
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.
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:
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 |
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.
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.
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 on after the other, i.e. running in a system configured with maxConcurrentLobbyCalls=1.
This means that is ok to have 2 “category red” but nothing more or 5 “category yellow” etc.
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 “%”.