The author is wang Yuansheng, founder of Shenzhen Branch Technology, member of Apache APISIX PPMC, initiator of OpenResty community and author of OpenResty Best Practices.

I first heard about Envoy at a technology forum organized by CNCF. The presenter, Bara Bara, talked a lot, remembered nothing but a particularly novel concept called “communication bus”, then googled what the Envoy was, and found this description on the website:

Envoy is an L7 proxy and communication bus designed for large modern SOA (Service-oriented Architecture) architectures

In other words, Envoy created an L7 proxy software to solve the Server Mesh domain. Here I found a picture on the Internet, and I understand the following deployment architecture of Envoy. (If you are wrong, please teach the boss)

Since it is the agent software of L7, as an old driver who has been mixing with OpenResty community for years, I couldn’t help but use it to make a comparison.

We chose Apache APISIX, which is an API gateway based on OpenResty. (L7 proxy with routing, authentication, traffic limiting, dynamic upstream, etc.)

Why choose it, because there is a community to share when I heard that this goods routing implementation is very good, just our current business routing system at random, scratched under the APISIX source code, found that is really 6 to fly up, hanging dozen I have seen the same product, so impressed, it!

Here’s a PIC from the APISIX website. It’s worth a thousand words to see how this thing works.

Let’s get started. First, we went to the official website to find the latest versions of the two products:

Apache APISIX 1.5 and Envoy 1.14

(Author’s latest edition as of this writing)

Preparing the Build Environment

  • Stress test client: WRK;
  • The main test indicators include: gateway delay, QPS and whether linear expansion;
  • Test environment: Microsoft Cloud Linux (Ubuntu 18.04), Standard D13 v2 (8 vcpus, 56 GiB memory);
  • Test method 1: Use single-core run horizontal comparison (because they are based on epoll IO model, so use single-core pressure test to verify their processing power);
  • Test method 2: use multi-core lateral comparison operation, mainly to test both in adding more | thread (process) under the scenario of the overall processing capacity will be linear growth;

Test scenarios

Here, we use NGINX to build an upstream server and configure two workers to directly respond to 4K content after receiving the request. Please refer to the configuration as follows:

server { listen 1980; access_log off; location = /hello { echo_duplicate 400 "1234567890"; }}Copy the code
  • The network architecture is as follows :(green normal load, not full. The red is high voltage load, which requires the process to run out of resources, mainly CPU)

The routing configuration

First we find the configuration guide for Getting Started with APISIX. We add a route to /hello with the following configuration:

Curl http://127.0.0.1:9080/apisix/admin/routes/1 - PUT X - d '{, "uri" : "/ hello," "upstream" : {" type ": "Roundrobin", "nodes" : {" 127.0.0.1:1980 ": 1}}} 'Copy the code

Note that the proxy_cache and proxy_mirror plug-ins are not started because Enovy does not have similar functionality;

Then we add a route to the Envoy using the official pressure gauge guide:

Static_resources: listeners: - Name: listener_0 address: socket_address: {address: "0.0.0.0", port_value: 10000 } filter_chains: - filters: - name: envoy.http_connection_manager config: generate_request_id: false, stat_prefix: ingress_http route_config: name: local_route virtual_hosts: - name: local_service domains: ["*"] routes: - match: { prefix: "/hello" } route: { cluster: service_test } http_filters: - name: envoy.router config: Dynamic_stats: false Clusters: - name: service_test connect_TIMEOUT: 0.25s type: LOGICAL_DNS dNS_lookup_family: V4_ONLY lb_policy: ROUND_ROBIN hosts: [{socket_address: {address: "127.0.0.1, port_value: 1980}}] circuit_breakers: thresholds: - priority: DEFAULT max_connections: 1000000000 max_pending_requests: 1000000000 max_requests: 1000000000 max_retries: 1000000000 - priority: HIGH max_connections: 1000000000 max_pending_requests: 1000000000 max_requests: 1000000000 max_retries: 1000000000Copy the code

The generate_request_id, dynamic_STATS, and circuit_breakers sections above, which are on by default inside the Envoy, are not used in this Envoy and need to be explicitly turned off or set to a large threshold to improve performance. (who can explain to me why this thing configuration is so complicated -_-!)

Pressure test results

For a single route, no plug-in is enabled. Enable different cpus to perform a full load pressure test. Note: NGINX calls the number of workers, Envoy is concurrent, to unify the number of workers.

Note: Raw data is available in gist preview. (Gist.github.com/aifeiasdf/9…)

QPS: The number of requests completed per second, the more the better, the higher the number of requests can be completed per unit of time. According to the QPS results, the performance of APISIX is about 120% of the Envoy, and the more cores there are, the larger the QPS difference will be.

Latency: Latency per request. The smaller the value, the better. It represents how long it takes for each request to receive a response after it was sent. For the reverse proxy scenario, the smaller the value, the less impact on the request. As a result, Envoy has 6-10% more latency per request than APISIX, and the more cores there are, the greater the latency.

Can see both work in a single thread | process mode, QPS and Latency two indicators gap is not big, but the gap with the increase of working thread | process they enlarge gradually, I analysis may have the following two reasons, Is it possible that NGINX has more advantages to interact with the IO model of the system by using multiple workers in high concurrency scenarios? On the other hand, it may be that NGINX itself is relatively “stingy” in the use of memory and CPU in implementation. The cumulative performance advantages of this will be evaluated in detail in the future.

conclusion

In general, APISIX is slightly better than Envoy in response latency and QPS. Because NGINX’s multi-worker collaboration has more advantages in high concurrency scenarios, APISIX improves performance more significantly than Enovy after multiple worker processes are started. Envoy’s bus design gives it unique advantages in handling east-west traffic, and APISIX’s performance and latency give it massive capacity in handling north-south traffic. It is right to choose the right components and plug-ins to build your own service according to your business scenario.

About the Apache APISIX

Apache APISIX is a dynamic, real-time, high-performance open source API gateway, providing load balancing, dynamic upstream, gray publishing, service fuse, identity authentication, observable and other rich traffic management functions. Apache APISIX helps companies quickly and securely handle API and microservice traffic, including gateways, Kubernetes Ingress, and service grids.

World has hundreds of companies using Apache APISIX processing key business flow, covering financial, Internet, manufacturing, retail, operators, etc., such as NASA (NASA), the European Union, letter of digital factory, Air China, China mobile, tencent, huawei, weibo, netease, shell to find room, 360, taikang, nai snow tea, etc.

Over 200 contributors create Apache APISIX, the world’s most active open source gateway project. Smart developers! Come join this active and diverse community and bring more beautiful things to the world!

  • Apache APISIX Project address: github.com/apache/apis…
  • Apache APISIX website: apisix.apache.org/zh/