Now Reading
How is Apache APISIX Quick?

How is Apache APISIX Quick?

2023-06-12 02:36:57

“Excessive velocity,” “minimal latency,” and “final efficiency” are sometimes used to characterize Apache APISIX. Even when somebody asks me about APISIX, my reply all the time consists of “high-performance cloud native API gateway.”

Efficiency benchmarks (vs. KongEnvoy) verify these traits are certainly correct (test yourself).

High speed, minimum latency, and ultimate performance

Tests run for 10 rounds with 5000 distinctive routes on Customary D8s v3 (8 vCPUs, 32 GiB reminiscence).

However how does APISIX obtain this?

To reply that query, we should have a look at three issues: etcd, hash tables, and radix timber.

On this article, we’ll look beneath the hood of APISIX and see what these are and the way all of those work collectively to maintain APISIX sustaining peak efficiency whereas dealing with vital visitors.

etcd because the Configuration Heart

APISIX makes use of etcd to retailer and synchronize configurations.

etcd is designed to work as a key-value retailer for configurations of large-scale distributed methods. APISIX is meant to be distributed and extremely scalable from the bottom up, and utilizing etcd over conventional databases facilitates that.

APISIX architecture

One other key indispensable function for API gateways is to be extremely accessible, avoiding downtime and information loss. You’ll be able to effectively obtain this by deploying a number of cases of etcd to make sure a fault-tolerant, cloud native structure.

APISIX can learn/write configurations from/to etcd with minimal latency. Modifications to the configuration information are notified immediately, permitting APISIX to observe solely the etcd updates as a substitute of polling a database steadily, which may add efficiency overhead.

This chart summarizes how etcd compares with different databases.

Hash Tables for IP Addresses

IP address-based allowlists/denylists are a typical use case for API gateways.

To attain excessive efficiency, APISIX shops the checklist of IP addresses in a hash desk and makes use of it for matching (O(1)) than iterating via the checklist (O(N)).

Because the variety of IP addresses within the checklist will increase, the efficiency impression of utilizing hash tables for storage and matching turns into obvious.

Below the hood, APISIX makes use of the lua-resty-ipmatcher library to implement this performance. The instance under exhibits how the library is used:

native ipmatcher = require("resty.ipmatcher")
native ip ={


The library makes use of Lua tables that are hash tables. The IP addresses are hashed and saved as indices in a desk, and to seek for a given IP deal with, you simply need to index the desk and check whether or not it’s nil or not.

Storing IP addresses in a hash table

To seek for an IP deal with, it first computes the hash (index) and checks its worth. Whether it is non-empty, now we have a match. That is performed in fixed time O(1).

Radix Timber for Routing

Please forgive me for tricking you into a knowledge constructions lesson! However hear me out; that is the place it will get attention-grabbing.

A key space the place APISIX optimizes efficiency is route matching.

APISIX matches a route with a request from its URI, HTTP strategies, host, and different info (see router). And this must be environment friendly.

When you have learn the earlier part, an apparent reply could be to make use of a hash algorithm. However route matching is hard as a result of a number of requests can match the identical route.

For instance, if now we have a route /api/*, then each /api/create and /api/destroy should match the route. However this isn’t potential with a hash algorithm.

Common expressions will be an alternate resolution. Routes will be configured in a regex, and it may match a number of requests with out the necessity to hardcode every request.

If we take our earlier instance, we are able to use the regex /api/[A-Za-z0-9]+ to match each /api/create and /api/destroy. Extra complicated regexes may match extra complicated routes.

However regex is gradual! And we all know APISIX is quick. So as a substitute, APISIX makes use of radix timber that are compressed prefix timber (trie) that work rather well for quick lookups.

Let’s take a look at a easy instance. Suppose now we have the next phrases:

  • romane
  • romanus
  • romulus
  • rubens
  • ruber
  • rubicon
  • rubicundus

A prefix tree would retailer it like this:

Prefix tree

The highlighted traversal exhibits the phrase “rubens.”

See Also

A radix tree optimizes a prefix tree by merging youngster nodes if a node solely has one youngster node. Our instance trie would seem like this as a radix tree:

Radix tree

The highlighted traversal nonetheless exhibits the phrase “rubens.” However the tree seems to be a lot smaller!

Whenever you create routes in APISIX, APISIX shops them in these timber.

APISIX can then work flawlessly as a result of the time it takes to match a route solely will depend on the size of the URI within the request and is impartial of the variety of routes (O(Ok), Ok is the size of the important thing/URI).

So APISIX will probably be as fast as it’s when matching 10 routes if you first begin out and 5000 routes if you scale.

This crude instance exhibits how APISIX can retailer and match routes utilizing radix timber:

Crude example of route matching in APISIX

The highlighted traversal exhibits the route /consumer/* the place the * represents a prefix. So a URI like /consumer/navendu will match this route. The instance code under ought to give extra readability to those concepts.

APISIX makes use of the lua-resty-radixtree library, which wraps round rax, a radix tree implementation in C. This improves the efficiency in comparison with implementing the library in pure Lua.

The instance under exhibits how the library is used:

native radix = require("resty.radixtree")
native rx ={
        paths = { "/api/*motion" },
        metadata = { "metadata /api/motion" }
        paths = { "/consumer/:title" },
        metadata = { "metadata /consumer/title" },
        strategies = { "GET" },
        paths = { "/admin/:title" },
        metadata = { "metadata /admin/title" },
        strategies = { "GET", "POST", "PUT" },
        filter_fun = operate(vars, opts)
            return vars["arg_access"] == "admin"

native opts = {
    matched = {}

ngx.say(rx:match("/api/create", opts)) 
ngx.say("motion: ", opts.matched.motion) 

ngx.say(rx:match("/api/destroy", opts)) 
ngx.say("motion: ", opts.matched.motion) 

native opts = {
    technique = "GET",
    matched = {}

ngx.say(rx:match("/consumer/bobur", opts)) 
ngx.say("title: ", opts.matched.title) 

native opts = {
    technique = "POST",
    var = ngx.var,
    matched = {}

ngx.say(rx:match("/admin/nicolas", opts)) 
ngx.say("admin title: ", opts.matched.title) 

The flexibility to handle a lot of routes effectively has made APISIX the API gateway of alternative for many large-scale projects.

Look beneath the Hood

There may be solely a lot I can clarify concerning the internal workings of APISIX in a single article.

However the most effective half is that the libraries talked about right here and Apache APISIX are entirely open source, which means you may look beneath the hood and modify issues your self.

And for those who can enhance APISIX to get that closing little bit of efficiency, you may contribute the changes again to the undertaking and let everybody profit out of your work.

Source Link

What's Your Reaction?
In Love
Not Sure
View Comments (0)

Leave a Reply

Your email address will not be published.

2022 Blinking Robots.
WordPress by Doejo

Scroll To Top