在2015年12月，亚马逊推出了他们的VPC NAT网关服务 ，这个服务基本上是创build自己的托pipe替代scheme（与NAT实例相比 ， 它看起来非常好 ）。
我正要部署自己的NAT实例，并决定使用NAT网关来替我省下configuration和维护自己的NAT服务的麻烦。
该服务的工作原理如同广告一样，直到我注意到一个奇怪的行为，我一直是一个愉快的chappy。
我使用NAT网关后面的EC2实例来testing一堆网站，每个EC2实例运行最多4个并行的Firefox +seleniumtesting。 我注意到以前在其他地方运行良好的testing在这个环境下一直没有成功。
因此，我创build了两个t2.large实例，一个具有公共弹性IP并直接访问Internet; 另一个带有私有IP，位于NAT网关后面。
以下是针对某些网站运行apache基准testing的结果：
EIP
ab -kn 1000 -c 20 https://www.pinterest.com/ (...) Time taken for tests: 17.331 seconds ab -kn 1000 -c 20 http://speedtest.ftp.otenet.gr/files/test100k.db (...) Time taken for tests: 9.610 seconds ab -kn 1000 -c 20 http://www.bbc.com/ (...) Time taken for tests: 5.890 seconds NAT
ab -kn 1000 -c 20 https://www.pinterest.com/ (...) Time taken for tests: 25.980 seconds ab -kn 1000 -c 20 http://speedtest.ftp.otenet.gr/files/test100k.db (...) Time taken for tests: 14.920 seconds ab -kn 1000 -c 20 http://www.bbc.com/ (...) Time taken for tests: 6.552 seconds
在NAT网关后面的服务器在很多情况下比直接连接的服务在性能上大大优于其他服务。
AWS表示，该服务“支持高达10Gbps的突发”，这比我使用的个别实例更能做到。
我注意到，如果我closures保持活动（即-k ）的performance变得相似：
ab -n 1000 -c 20 https://www.pinterest.com/ EIP: 18.316 seconds NAT: 17.763 seconds
这个巫术是什么？ 这是怎么回事？ 我的基准是否相关？
你有什么经验吗？
我的NAT网关设置是新鲜的，没有任何习俗。 这是我的命令结果
siege -c 100 https://www.pinterest.com -v
与Nat网关：
Transactions: 15012 hits Availability: 100.00 % Elapsed time: 140.40 secs Data transferred: 335.43 MB Response time: 0.43 secs Transaction rate: 106.92 trans/sec Throughput: 2.39 MB/sec Concurrency: 46.39 Successful transactions: 15012 Failed transactions: 0 Longest transaction: 5.90 Shortest transaction: 0.29
没有Nat Gateway
Transactions: 11519 hits Availability: 100.00 % Elapsed time: 107.02 secs Data transferred: 257.20 MB Response time: 0.43 secs Transaction rate: 107.63 trans/sec Throughput: 2.40 MB/sec Concurrency: 46.33 Successful transactions: 11519 Failed transactions: 0 Longest transaction: 4.02 Shortest transaction: 0.28
几乎一样。