Performance Tips on Building Visual Builder Applications with Fusion REST Services

I have been lucky to help a lot of Enterprise customers to build Visual Builder-based applications. Once these applications go live, I see a common pattern of complaints about performance issues. These complaints will show a lot of customer frustration as the investment is already made and customers do not expect Oracle applications to perform badly. Guess what? Often times it is the development practices that are the leading cause of the majority of those issues. I am mentioning a few key causes of these performance issues:

Disclaimer: None of the ideas explained in this post is rocket science. However, they still cover the majority of the reasons for almost all those performance complaints.

Data Set Size

ADF and Adaptive Search REST services by default have an optimized recordset size. This can be changed by the limit parameter. This parameter is blindly changed to a larger number such as 500 or in some cases 5000 in an attempt to get all the data.

This is not optimal. Beyond the visible viewport, users will have a hard time really making sense of that large data. Use either “load on scroll” (Twitter style) or actual buttons to load more data when the user needs to see more.

If you are trying to generate summary numbers based on 5000 rows accessible to the user then this is a big NO-NO. Do those calculations at the server-side and pull the summary numbers.

Pull What You Really Need

Similar to the above where you should optimize how many rows you pull, you should also pay close attention to which attributes/fields you need for these rows. So, if you need emp id and emp name then do not pull emp dept and 20 other attributes. I have seen like 200 attributes pulled when a user does not need more than 25.

This can massively reduce the payload size that server needs to process and the amount of data that travels via the network.

Minimize Initial Page Load

Enterprise applications are data intensive and often I observe 10+ service calls are made on page load. A number of calls may not be avoidable but calling them all before even the page finishes rendering is something that needs to be avoided. Carefully look into your code flow and see if some of those calls can be made later. A trick that does wonders is trying to load the read-only view of the page and hence only making the calls that need to pull data from a much smaller number of services. In Oracle’s World, a lot of LOV calls can be avoided initially and an edit mode can make those calls much later.

Use Browser Caching

A significant amount of data rarely changes in the enterprise applications and it is a common practice to try to pull everything from the server-side using those 15–20 API calls at the initial page load. Carefully examine what data truly needs to be pulled every single time. And make use of browser caching to cache things like LOV lists, configuration setups, etc.

Read Documentation

Oracle invests significantly in ensuring that released features are explained well via release guide or developer guide. Looking into can really help in finding those useful flags or parameters that can help in improved performance by applying those optimizations.

Just in case you are wondering where is VBCS in this post? Well, Visual Studio is the next generation of application development platform which is used by a large number of enterprise customers building applications in the Oracle ecosystem. And, the most popular way to consume data for these applications is REST services. Users often get into this false impression that Visual Studio has issues when the underlying issues are somewhere else.

Please give me a few claps if you liked this post. :)