在 AWS 上面的 OpenVPN Server 效能
source link: https://blog.gslin.org/archives/2021/08/04/10265/%e5%9c%a8-aws-%e4%b8%8a%e9%9d%a2%e7%9a%84-openvpn-server-%e6%95%88%e8%83%bd/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
在 AWS 上面的 OpenVPN Server 效能
這篇會陸續更新，還一直在調整...
最近在在調整跑在 Amazon EC2 上 OpenVPN server 的效能，要想辦法把 network throughput 拉高，當作在導入 WireGuard 之前的 workaround，但看起來還是頗有用，記錄一下可以調整的部份...
在還沒灌大量流量前是用 t3a.nano (開 Unlimited mode)，然後會觀察到的瓶頸是 OpenVPN 的 daemon 吃了 100% CPU loading，最高速度卡在 42MB/sec 左右。
第一個想到的是看看 OpenVPN server 有沒有可以使用多 CPU 的方式，但查了資料發現 OpenVPN server 無法使用 threading 或是 fork 之類的方法善用多顆 CPU，所以就開始想其他方法...
接著看到我們目前用的是 AES-256-CBC 了，網路上很多文章都有提到 AES-128-CBC 會快一些，但我們的 OpenVPN client 已經是設死都用 AES-256-CBC 了，這個就沒辦法了...
而第一個可行的解法是把 AMD-based 的 t3a.nano 換成 ARM-based 的 t4g.nano，還是 100% 的 CPU loading，但直接多了 50%+ 的效能，到了 69MB/sec。
第二個解法是找資料時發現的 fast-io 參數，加上去以後可以再快一些，到 77MB/sec。
有了這兩個 workaround 應該就堪用了，接下來是發現在傳大量資料跑一陣子後速度會掉下來，於是開了兩台 t4g.nano 用 iperf 對測了一下，發現會逐步掉速：
- 前 15 秒可以直接到 5Gbps，就是 AWS 網頁上宣稱的最高速度，接下來降到 800Mbps 左右。
- 到 180 秒左右後降到 300Mbps。
- 到 210 秒左右後回到 800Mbps。
- 到 300 秒左右後降到 500Mbps。
- 到 300 秒左右後降到 300Mbps。
- 到 1260 秒左右後降到 30Mbps，後面就一直維持這個速度了。
看起來 network bandwidth credit 是分階段的，但 30Mbps 真的有點低...
在換成四倍大的 t4g.small 測試後發現也只能到 40MB/sec 左右 (比較疑惑的是，居然不是四倍？)，目前上了 c6g.medium，但看起來網路的部份也還是有瓶頸，在 46MB/sec 左右，要再想一下下一步要怎麼調整...
但以目前看到的情況總結，如果能用 ARM 架構就儘量用，效率與價錢真的是好 x86-64 不少...
Related
實際比較 Linode 的 Dedicated 主機與 AWS 的 c5.*
先前有提到 Linode 出了 Dedicated 主機：「Linode 推出 Dedicated CPU Instances」，現在找機會測試看看，拿了 Linode 的 Dedicated (4GB) 與 AWS 的 c5.large 比較，同樣都是 2 vCPU 與 4GB RAM。 這邊用了 n-st/nench 與 OpenSSL 的 speed (包括了 aes、md5、rsa、sha1 與 sha256) 測試，我把結果都貼到這邊：「Linode (Dedicated 4GB) v.s. AWS (c5.large)」。 可以看到在 CPU 方面主要的差異是 Linode 用的是 AMD，而 AWS 用的是 Intel，所以就會有蠻多不同的數字表現... 如果仔細看 OpenSSL…
February 13, 2019In "AWS"
AWS 推出了 ARM 平台上 T 系列的機器
前幾天發現在 AWS Web Console 上開 EC2 機器時，選 t3a 後本來可以選的「T2/T3 Unlimited」變成只叫「Unlimited」，心裡猜測有東西要推出，然後這幾天看到消息了... 這次 AWS 推出了 t4g 系列的機器，而這邊的 g 如同慣例，指的是 ARM 的 Graviton2：「New EC2 T4g Instances – Burstable Performance Powered by AWS Graviton2 – Try Them for Free」。 目前公司在用的 ap-southeast-1 沒有在支援的地區，只好去 us-east-1 上玩： T4g instances are available today in US East (N. Virginia,…
September 17, 2020In "AWS"
最新的 Firefox 56 對 AES-GCM 效能的改善
昨天釋出的 Firefox 56 對於 AES-GCM 在老電腦上改善了不少效能：「Improving AES-GCM Performance」。 首先是 Firefox 自己的數據分析，可以看到 AES-GCM 佔目前加密連線裡的大宗，再來是 AES-CBC： 先以 Linux 64bits 環境的數據來看，Firefox 56 的 NSS 3.32 大幅改善了老電腦的效能 (不支援 AES-NI 硬體加解密的 CPU，甚至是不支援 PCLMUL 的 CPU，以及不支援 AVX 的 CPU)： 在 Linux 32bits 環境上則是連預設值大幅改善，不過用的人應該少很多了： Windows 下則是因為 64bits 或是 32bits 都有足夠的使用者，所以平常就花了不少力氣。但也可以看出對於老電腦的速度提升： Mac (64bits only) 算是這次比較大的提升，連新電腦的預設值都大幅變快： 加上之後陸續的改善 (尤其是下一版 Firefox…
September 30, 2017In "Browser"
Author Gea-Suan LinPosted on August 4, 2021August 4, 2021Categories AWS, Cloud, Computer, Hardware, Murmuring, Network, Service, Software, VPNTags 256, aes, amazon, amd, arm, aws, c6g, cbc, client, cloud, cpu, ec2, instance, loading, network, openvpn, performance, server, service, speed, t3a, t4g, vpn, workaround Leave a Reply Cancel reply
Your email address will not be published. Required fields are marked *
Comment
Name *
Email *
Website
Notify me of follow-up comments by email.
Notify me of new posts by email.
Post navigation
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK