How is Apache APISIX Fast? | Hacker News Reader

How is Apache APISIX Fast?

api7.ai

46 pointsthunderbong22 comments

Not encouraging that in the first graph they truncate the y-scale to make the performance appear three times better visually, while it is actually 40% better.

I don’t see how you could get misled when the peaks are annotated and immediately and clearly visible.

The graph is zoomed in. The Y axis doesn't start at zero, so it appears to be a larger difference at first glance than it actually is.

> I don’t see how you could get misled when the peaks are annotated and immediately and clearly visible.

This is a textbook graphing error, or worse graphing manipulation. Humans perceive proportions, and not including the origin of a graph gets these plots out of whack.

Indeed, see for example https://www.heap.io/blog/how-to-lie-with-data-visualization

I see how someone can avoid being misled, but I don’t see how can someone not see someone being misled.

It's perfectly clear to me. Little scope for confusion IMO.

"High speed," "minimum latency," and "ultimate performance" are often used to characterize Apache APISIX.

"Highly misleading graphs" now as well.

Perhaps it is best to charitably assume an oversight rather than a deliberate misrepresentation for PR reasons - which obviously would not lend credence to the product.

It appears they are making an assumption that the type of person who reads blog posts about the inner workings of an API gateway also knows how to read a well labeled graph.

>To achieve high performance, APISIX stores the list of IP addresses in a hash table and uses it for matching (O(1)) than iterating through the list (O(N)).

For IP allow/deny lists, unless the list were very large, I imagine it would be faster on most hardware to use an array than a map due to LX caches. It would have been cool to see an adaptive approach based on the size (e.g. for values of N over X, we use a map, otherwise an array). Maybe these lists are much larger in production than my assumptions about their size.

> I imagine it would be faster on most hardware to use an array than a map due to LX caches.

I didn't understood your point. I mean, a hash map is basically an array whose index is calculated from a key.

Those arrays usually contain pointers to other data structures, allocated on the heap in different places, which often results in a cache miss / cpu stall. It's still a constant time lookup, but for small values of N, avoiding the cache misses is often faster, even with an O(N) algorithm.

Also you do need to calculate that hash key, which isn't free either. I generally found that lookups in lists are faster than hashmaps for sizes smaller than about 10 or so, but details may vary on the exact implementation etc.

This is the origin of the famous quote from Rob Pike which goes something like "Simple data structures are better when n is small and n is almost always small". It hasn't aged as well as he might have liked, given that sometimes n gets really really big now, but the point still holds- in lots of common use cases simple algorithms with low constant factors dominate fancy algorithms with theoretically better O() up to a certain threshold data scale.

In this case it would presumably be up to a certain number of routes and/or ip addresses.

I have been experimenting in this space, just wanted to share.

I was playing around with h2o this weekend, I can get <4ms max latency with 0.8ms average latency at 10000 RPS on my laptop. This was surprising to me because a basic varnish setup on my laptop still gets 10ms+ avg latency.

It also has this nice integration of MRuby with Rack so you can do arbitrary request rewriting: https://h2o.examp1e.net/configure/mruby.html

I think Envoy has some key features especially in the load balancing area that make it more attractive though. I also like the support for dynamic configuration in Envoy.

I’m curious if anyone else has been experimenting with stuff like this and what your experiences are?

It's marginally faster than Envoy and lighter on features. I personally would stick with Envoy

In my experience it's much easier to configure and deploy.

Envoy or apisix

Apisix. Envoy is so hard that there's entire suites of products (ambassador, gloo, etc) just to make it easier to configure.

APISIX has a similar architecture as most of those products, it's just that it's specific to APISIX where the control plane is kept separate from the proxy and it configuration is pushed. The envoy management API is standardized enough now that there's a pretty big ecosystem built up around it, hence lots of open source and non-open source innovation.

I am still happy with KrakenD and it's completely stateless approach to things, although I didn't do any high volume scaling on it so far :)

Why wouldn't everyone just use radix trees?

Reply on news.ycombinator.com