background
July 13, 2022 Google Cloud released the first VM-Series preview of Tau T2A based on Arm® architecture. The T2A VM is powered by an Ampere® Altra® Arm-based processor that Google claims has an attractive price and excellent single-threaded performance.
Notably, Ampere® Altra® Arm is a cloud-native processor, so Tau T2A virtual machines based on Ampere® Altra® Arm processors can run scale-out cloud-native applications in an efficient manner.
So what is the actual experience and performance? Let's take a cloud-native API gateway as an example to show you the performance of the Google Cloud Tau T2A virtual machine. Here, we choose Apache APISIX for installation testing on Google Cloud Tau T2A server environment.
Apache APISIX is a cloud-native, high-performance, scalable API gateway. Based on NGNIX + LuaJIT and etcd, APISIX has the characteristics of dynamic routing and plug-in hot loading compared with traditional API gateways, which is especially suitable for API management under cloud native architecture.
Preliminary preparation
First, you need to start a T2A instance on Google Cloud, and choose Ubuntu 20.04 as the operating system.
Then install Docker to facilitate the subsequent use of containerized methods to install and deploy Apache APISIX.
sudo apt-get update && sudo apt-get install docker.io
Deploy Apache APISIX
Apache APISIX uses etcd as the configuration center, so you need to start an etcd instance first.
sudo docker run -d --name etcd \
-p 2379:2379 \
-e ETCD_UNSUPPORTED_ARCH=arm64 \
-e ETCD_LISTEN_CLIENT_URLS=http://0.0.0.0:2379 \
-e ETCD_ADVERTISE_CLIENT_URLS=http://0.0.0.0:2379 \
rancher/coreos-etcd:v3.4.16-arm64
Start an instance of Apache APISIX.
sudo docker run --net=host -d apache/apisix:2.14.1-alpine
Register the route.
curl "http://127.0.0.1:9080/apisix/admin/routes/1" \
-H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PUT -d '
{
"uri": "/anything/*",
"upstream": {
"type": "roundrobin",
"nodes": {
"httpbin.org:80": 1
}
}
}'
Access the test.
curl -i http://127.0.0.1:9080/anything/das
HTTP/1.1 200 OK
.....
Google Cloud T2D vs Google Cloud T2A
From the above operations, the installation and compatibility test of Apache APISIX on Google Cloud Tau T2A can be successfully completed. So what is the actual performance of Google Cloud T2A? Next, we will use Apache APISIX to do performance test comparisons on Google Cloud T2A and Google Cloud T2D to see their actual performance.
Google Cloud T2D is another model of Google Cloud Tau series, which is based on AMD x86 architecture, so the above etcd installation steps are slightly different:
sudo docker run -d --name etcd \
-p 2379:2379 \
-e ETCD_LISTEN_CLIENT_URLS=http://0.0.0.0:2379 \
-e ALLOW_NONE_AUTHENTICATION=yes \
-e ETCD_ADVERTISE_CLIENT_URLS=http://0.0.0.0:2379 \
bitnami/etcd:3.4.16
For simplicity, only one Worker is enabled in this test APISIX, and the following performance test data are run on a single-core CPU.
Scenario 1: Single upstream
In this scenario, a single upstream (without any plugins) will be used to test the performance of APISIX in pure proxy back-to-origin mode. Test in local environment:
# apisix: 1 worker + 1 upstream + no plugin
# 注册路由
curl http://127.0.0.1:9080/apisix/admin/routes/1 \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
"uri": "/hello",
"plugins": {
},
"upstream": {
"type": "roundrobin",
"nodes": {
"127.0.0.1:1980":1
}
}
}'
Scenario 2: Single upstream + two plugins
In this scenario, a single upstream and two plug-ins will be used to test the performance of APISIX when two core performance-consuming plug-ins, limit-count
and prometheus
are enabled.
# apisix: 1 worker + 1 upstream + 2 plugins (limit-count + prometheus)
# 注册路由
curl http://127.0.0.1:9080/apisix/admin/routes/1 \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
"uri": "/hello",
"plugins": {
"limit-count": {
"count": 2000000000000,
"time_window": 60,
"rejected_code": 503,
"key": "remote_addr"
},
"prometheus": {}
},
"upstream": {
"type": "roundrobin",
"nodes": {
"127.0.0.1:1980":1
}
}
}'
data comparison
In the above two scenarios, relevant tests and comparisons were carried out from the two levels of request QPS ( queries per second ) and delay time . The result is as follows:
- QPS comparison
- Request Latency Comparison
single upstream | Single upstream + two plugins | |||
---|---|---|---|---|
Google Cloud T2D | Google Cloud T2A | Google Cloud T2D | Google Cloud T2A | |
QPSrequest/sec | 12500 | 11300 | 10600 | 9900 |
Latency(ms) | 1.26 | 1.39 | 1.45 | 1.60 |
It can also be seen from the above data that in network IO-intensive computing scenarios such as API Gateway, T2A still has a performance gap compared with T2D virtual machines of the same series. But another good news is that the price of T2A is about 10% cheaper than T2D under the same configuration. In the actual machine selection, users can make flexible decisions according to their own business volume.
Summarize
This article mainly uses Apache APISIX to compare the performance of Google Cloud T2A and Google Cloud T2D. It can be seen that in network IO-intensive computing scenarios such as API gateways, Google Cloud T2A is not so bright compared to T2D, but as Google Cloud's first attempt under the Arm architecture, I believe it will be in the Arm architecture. The virtual machine continues to exert its strength, and I also look forward to its subsequent iteration performance.
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。