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.
It is for these reasons that we decided at Eradani to implement APIs in JavaScript. JavaScript is blazingly fast at parsing JSON and translating it to something the IBM i can understand. And JavaScript’s asynchronous architecture is built specifically to handle high volumes of requests simultaneously without the complexity of coding and managing threads. By moving the API layer to JavaScript we have seen dramatic performance gains in existing IBM i API applications. We recently ran a load test of a customer’s API that made the roundtrip to the IBM i in 80 microseconds (.00008 seconds) on a ¼ core partition and successfully simulated 250,000 simultaneous requests hitting a 1 core IBM i partition.
To make it easy for IBM i developers to take advantage of the speed of JavaScript APIs, we have recently added API generators to our Eradani Connect product that will create the code for your APIs automatically. You simply need to identify the data you are sending and receiving and any functions you want to call. Building high performance APIs for your IBM i applications has never been easier.
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://eradani.com/eradani-blog/.
