As a market-leading Full Lifecycle API technology, many large enterprises are using IBM API Connect to drive very large digital transformation projects.

For those customers, performance and scale matter a whole lot—especially when they have the potential to have hundreds of people hitting their API Catalog at any one time. 

Considering those enormous growth requirements from our IBM API Connect customers, we’ve spent time in Fix Pack 8 to allow these customers to scale-out even further.

Rationale

During our root cause analysis, we determined that application performance was dictated by two key factors: the number of items fetched and the number of items rendered. The former was causing slow API response times, and the latter was causing bad performance in the page itself. 

The initial implementation did not have the following:

• The capability to request a subset of results (i.e., “limit” criteria in queries).
• The capability to “jump” to a specific results (i.e., “offset” criteria in queries).
• Large enough datasets that would impact performance in a meaningful way.

As customers increased their API Connect usage, the performance of the application deteriorated in proportion to their data growth. Since the impact was felt on both the client and server sides of the product, we needed to coordinate with the backend teams to decide on a unified solution. On the client-side, we decided to use the pagination component from the Carbon Design System, an IBM solution we already use in API Connect. For the server-side, specific APIs were enhanced to support the limit and offset criteria in request queries.

Implementation

Using the Carbon Pagination Component, we were able to add pages, next buttons, and items-per-page features to various list pages. Modifying the request queries to fetch only a subset of database entries from the server instantly improved both the response and render times of each paginated page.

For pages where basic pagination wasn’t possible, we decided to create new pages that supported the pieces that needed paginating. For example, the application page in the API Manager previously used an accordion which listed data for each subscription. As the number of subscriptions increased for each application, the performance of the entire component also would also degrade. To resolve this, the subscriptions feature was “split” into a new paginated page to keep the application page’s performance consistent.

For pages with only partial pagination support, we created a custom “pseudo”-pagination solution. This basically allows for paging using only the “back” and “forward” buttons that smartly compute where you should be. The algorithm recursively fetches results and limits the number of items returned based on what we deem as “acceptable” to maintain performance. As a minimal working solution, the goal was to make sure the page was still usable when the “peak” number of results were returned. 

Due to the limitations of using this approach, we had to remove “page jumps,” “total pages,” and “total results” for pages using this method. This is definitely a temporary measure and any affected pages will be upgraded to basic pagination once the relevant APIs enhancements made are available.

Results

Before pagination, the time it took to load a page would range from slow to infinite. More data in the database meant slower load times. After pagination, performance increased substantially due to the reduced number of items returned. Primarily, the page rendering was decoupled from the total number of items in the database. 

The following table represents the fruits of our labour:

Learn more about IBM API Connect.