Performance is not only a highly complex topic but also a moving target as business demands and technologies are constantly changing. What you design today as a highly performing business application may turn out to be a millstone around your neck within a few short years with the current rate of change. It’s important to constantly evaluate performance to ensure the best experience for your customers, whether external or internal to your business.

There are many factors that can impact the performance of a business application. This blog only touches on a few of those factors at a very high level, and is focused specifically on the IBM i platform. Since every business application is unique, the impact each of these factors may have on the performance may vary considerably.

For a business to keep ahead of the competition, there is often pressure to be an early adopter of new technology. This can mean that it is an immature technology and any pitfalls related to performance may not be discovered until after quite a large development investment has been expended or until after the project has been delivered into a production environment. An example of how this may happen is the fairly widespread use of SOAP (Simple Object Access Protocol), a protocol for exchanging structured information across the Internet. SOAP was once the de-facto standard web services messaging format. Over time, SOAP has been viewed as anything but “Simple.” It’s far too complex and, in many situations, it’s considered to have a negative performance impact. A presentation from a recent conference Lessons Learned From Failure Of SOAP alludes to this problem.

The choice of both hardware platform and the database software can be very important for the performance of an application. Not all database software will necessarily support all the features of the database access in an application or provide the same level of performance for the same type of database requests. Many legacy applications on the IBM i use native I/O access to the DB2 database, which is usually very high performing. The types of applications being built today frequently use SQL to access the DB2 database and care must be taken that performance is not impacted by the incorrect usage of SQL requests. For example, selecting rows from a table with millions of rows – where there are no indexes matching the search criteria – may actually cause the reading of the whole file to provide the resulting dataset to satisfy the selection criteria rather than only reading a subset of the rows for native I/O access. Likewise, applications that are ported to another platform, where the DB2 native I/O access is replaced by SQL to access another non-DB2 database, may also experience performance degradation for the same reasons. It’s well worth spending time reviewing and optimizing database performance in any business application.

The choice of User Interface (UI) – rich client or browser – is a decision that determines how the business application must be designed to ensure the optimal performance. Since the browser is stateless, there are additional considerations that do not apply to rich client applications. For example, when using an MVC (Model-View-Controller) design pattern, you must ensure that the model objects persist on the server rather than being created and destroyed for each request (usually implemented via cookies or AJAX). Such an OO design also requires an appropriate hardware and software platform to ensure a minimal response time. The IBM Power 7 hardware and IBM i software is an example of one such hardware and software platform as described in this article LANSA platform on IBM POWER7 servers.

Finally, another consideration that is often overlooked is that a business application, especially for the web, can become a victim of its own success. What was once a high performing business application can become a poor user experience by the increasing demand on transaction volumes, perhaps never envisaged when the business application was first designed and implemented. It is necessary to consider the future scalability of the application. This may potentially be addressed via a combination of both software and hardware updates. There should always be a strategy in place for monitoring the performance of your critical business applications so that a proactive approach to performance issues can be taken rather than a reactive approach. Guidelines on how to develop a performance management strategy using the available IBM performance tools specific to the IBM i  7.1 platform are available for download from the IBM Information Center in the document Systems management performance.