A well designed API providing a valuable service to developers is guaranteed to attract increasing API call volumes yearly. How can your business keep up with these performance demands? A non-blocking architecture is your best choice to meet the growing performance demands of your API project. Read on for another installment in our Blog Series: Top 8 API Management Considerations for Winning Digital Strategies.

We recently discussed how Java-based API Gateways are more susceptible to security attacks. Today we’ll discuss why Java-based API Gateways, such as MuleSoft’s API Gateway, are also less performant than purpose built API Gateways, like IBM DataPower Gateway.

Java architecture limits Java API Gateway Performance 

Java-based API Gateways use a blocking, thread-per-request, model to process API traffic. This is because of the architecture supported by the underlying Java Virtual Machine (JVM). This architecture works well for applications with moderate concurrent load. However, the architecture is less robust and less performant due to frequent context switching and limited number of threads (see C10k problem here and here). This architecture also prevents developers from achieving linear scaling. The result is performance degradation as additional processing power is made available to the Java-based API Gateway.

A non-blocking API Gateway is designed for high performance

IBM’s API Gateway, based on IBM DataPower, is a key capability within IBM API Connect. IBM’s API Gateway uses a non-blocking event-driven I/O architecture which provides better performance and linear scale. Worker threads are relieved from having to handle a client request from start to completion. This provides a boost to the server’s scalability and enables the server to sustain higher throughput with lower response time. Also, server thread utilization is kept high because they are devoted for processing and not waiting, or blocked, for a response.

Native JSON and XML parsing ensures high performance

APIs send and receive data in either XML or JSON format. XML is the native data format for older SOAP-based APIs and JSON is the native data format for modern REST APIs. It is paramount for a gateway to be able to process and validate messages in both programming models at high speed.

Most APIs are still REST-ful facades on existing SOAP APIs, which rely on XML. As such, how well your API Gateway handles XML parsing will have a significant impact on your API performance. XML processing is a multi-tiered task due to the many layers of specifications that govern its use, such as XML Namespaces, XML Information Set, XML Schema, etc. These layers are all combined, and typically a generic parser handles scanning, XML normalization, namespaces, and well-formedness checking, as required by the XML specification, as well as validation. In fact, validation is usually an add-on in standard parsers, which has a substantial detrimental effect on the overall parser performance.

For instance, MuleSoft’s Java-based API Gateway utilize general-purpose functions to parse and process JSON and XML data. As such, processing large XML data sources will be very slow, often orders of magnitude slower than using a native parser. IBM’s API Gateway on the other hand has built-in parsers and compilers for JSON and XML parsing and processing. These are built from the ground-up using patented algorithms, and designed for XML and JSON message processing. MuleSoft’s JSON processing can be awkward and inefficient. With MuleSoft, to break down a simple JSON document and extract each record, we would typically need to transform the JSON entity to a hierarchy of Java structures, then extract the record list, and finally split the list with a splitter from the toolbox. This is extremely inefficient, error prone, and needless to say, low performance.

Pick your API Gateway wisely

In summary, an API Gateway with a non-blocking architecture and native JSON and XML parsing capabilities are critical to high performing APIs which minimize end user wait times. Unlike IBM API Connect, MuleSoft’s architecture relies on an a Java-based API Gateway that hinders the performance of its parsers, both XML and JSON, and ultimately affects the response time of your APIs.


Try IBM API Connect

Don’t take our word for it, use IBM API Connect for free and compare for yourself.

Talk to Us

Want to learn more about API Management or IBM API Connect? Contact us and our team will be in touch.

3 comments on"Ensuring High Performance of API Projects"

  1. what are the benefits of API connect

  2. “Java-based API Gateways use a blocking, thread-per-request, model to process API traffic. This is because of the architecture supported by the underlying Java Virtual Machine (JVM).”.

    What is this statement based on? The JVM supports non-blocking IO, as do all modern java based web servers.

Join The Discussion

Your email address will not be published. Required fields are marked *