[HN Gopher] How is Apache APISIX Fast?
       ___________________________________________________________________
        
       How is Apache APISIX Fast?
        
       Author : thunderbong
       Score  : 25 points
       Date   : 2023-06-12 07:36 UTC (15 hours ago)
        
 (HTM) web link (api7.ai)
 (TXT) w3m dump (api7.ai)
        
       | jjgreen wrote:
       | 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.
        
         | _a_a_a_ wrote:
         | It's perfectly clear to me. Little scope for confusion IMO.
        
         | chomp wrote:
         | I don't see how you could get misled when the peaks are
         | annotated and immediately and clearly visible.
        
           | fintler wrote:
           | 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.
        
           | rewmie wrote:
           | > 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.
        
         | mellosouls wrote:
         | _" 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.
        
       | davewritescode wrote:
       | It's marginally faster than Envoy and lighter on features. I
       | personally would stick with Envoy
        
         | angio wrote:
         | In my experience it's much easier to configure and deploy.
        
       | faizshah wrote:
       | 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?
        
       | coolgoose wrote:
       | 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 :)
        
       | collinvandyck76 wrote:
       | >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.
        
         | rewmie wrote:
         | > I imagine it would be faster on most hardware to use an array
         | than a map due to LX caches.
         | 
         | I don't understood your point. I mean, a hash map is basically
         | an array whose index is calculated from a key.
        
           | collinvandyck76 wrote:
           | 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.
        
       ___________________________________________________________________
       (page generated 2023-06-12 23:01 UTC)