As more IBM i users begin integrating APIs into their application development strategy, we are hearing increasing concerns about API performance. IBM i users are accustomed to the instantaneous response they get from their 5250 screens and the extremely high-speed performance they get from IBM i transaction processing. At the same time, web users expect the same kind of performance they get when they access Amazon, Google or other popular websites. It’s critical when we API enable our IBM i applications that we do it without introducing a slow connection layer that will satisfy neither kind of user.
There are two major elements to high performance: the speed with which a single transaction or a series of serial requests can be handled and the speed at which a high volume of simultaneous transactions can be processed.
If you are API enabling a user interface function for a limited number of users at low transaction volumes, then you should focus on the first issue. It is important to minimize the roundtrip time for a single request to ensure the user gets an immediate response. Users will quickly return to their green screens if the web performance is unsatisfactory.
The ability to rapidly process simultaneous requests is growing in importance as we are seeing an increasing number of IBM i users who are API enabling their IBM i applications for machine-to-machine communications or for public facing web interfaces with high request volumes. In those cases, it is important to focus on both issues. You must minimize the time to process a single transaction and maximize your ability to process simultaneous requests.
To minimize the time necessary to process a single transaction, you must be able to very rapidly translate messages coming from the web in a format like JSON or XML into IBM i structured data or parameters and vice versa. Then you need a high-speed connection layer for transmitting the data (like IBM’s native ODBC connector). In addition, if you are sending or receiving high volumes of simultaneous requests, you must be able to process them concurrently rather than serially.
In a coming blog post I’ll talk about changes you can make to your DevOps process in order to simplify and automate API development and deployment. For more information on APIs and your IBM i, check out my previous blog posts at https://www.eradani.com/eradani-blog/.