Amazon EC2等云基础设施已经在世界范围内证明了它的价值，其易于扩展、即开即用、按时计费等特性更彻底地解放了开发人员的创造性；然而请不要忽略，虚拟化环境曾一度被认为是应用程序及数据库的性能杀手。
尽管性能方面，云供应商一直在寻找着改善途径，但作为用户的我们，自己的性能优化手段也必不可少。在实体服务器上，Aerospike曾展示过百万TPS的峰值，而现在，我们则将致力于提升云应用的性能，彻底打破云不等于高性能这个流言。
我们做过各种各样的云实例对比，这里将展示的是基于C3.8xlarge，如何以每小时1.68美元的成本获得每秒百万事务数据库的性能。
以下博文为译文：
越高越好
这个报告记录了大量Amazon EC2实例上的实验，下面则是见证奇迹的时刻，如何调整参数和指令以得到如此等级的价格性能比。
除非另有说明，实验将忠实执行以下设置：
单Aerospike内存NoSQL数据库服务器运行在一个独立的Amazon实例上。 1000万个对象，每个对象大小在100字节（10 bins或者columns，每个大小10字节），我们尽可能的调整。让对象体积保持足够小，这样就可以将所有的研究对象放到内存中。 使用具备Java基准工具的 Aerospike Java客户端，客户端进程使用非服务器实例模式。最大化客户端负载，并将之并行连接到Aerospike服务器上，具体使用数量取决于所运行的服务器实例类型。 为了最大化Amazon基础设施上的负载，在内存中使用了分布在整个key space上的100%读负载。 我们使用 spot-Instances来节省成本，在性能测试期间Spot和按需实例的性能基本相同。
步骤1：选择实例类型
在选择实例时基本按照以下准则：可以内存支撑整个数据库；可以支撑事务速率的网络和CPU。
我们不考虑i2和hs1实例，因为尽管他们虽然具备高存储能力，但是却会限制应用程序的内存使用。
我们调研了大量的EC2实例类型：
R——内存密集
C——计算密集
M——R和C的平衡
T——1个入门级的主机
不同类型的实例拥有不同的网络能力，因此我们调研了每个类型，并测试他们的最高带宽限制，使用发包工具从尽可能多客户端推送更大体积的包。经过调研后，结果如下：
Moderate（上限是100MBps）
High（范围在300Mbps到1.8Gbps之间）
10 Gigabit（峰值在8.8 Gbps左右）
我们没有考虑t1和m1.small，因为Amazon给它网络性能标注为“Low”，这个主要鉴于在“Low”或者“Moderate”标注的实例上，网络性能往往会成为实例瓶颈。此外，测试时M系列实例还不具备增大网络的选项。
步骤2：选择虚拟机
Amazon使用的是Xen，一个支持半虚拟化（PV）和全虚拟化的开源虚拟化平台，同时Amazon还有硬件虚拟化选项。我们同时使用了两个类型：
Para Virtualized Machine。首先，我们选择了c3.8xlarge。虽然它的成本很高，但是我们觉得仍然大有可为。开始时，我们在EC2-Classic网络中使用了一个PV AMI；但是随后我们发现，这些被标注10Gbps上限的机器只能获得1.8 to 2.2 Gbps的能力，主机的速率被限制到每秒8.5万包左右。而在测试了C3.2xlarge之后，我们发现这个主机仍然存在速度限制。再看CPU使用率，我们发现在半虚拟化主机中，严重负载下虚拟层的CPU使用率将达到恐怖的40%。使用这些主机，在Aerospike上我们可以获得8.5万TPS，速度限制再次出现。 Hardware Virtualized Machine。在AWS的说明中，基于网络加强实例的HVM会提供更高的网络性能，用户每秒将获得更高的packets。而在根据我们的测试显示，在没有其他增项时，TPS足足增加了3倍。同等端配置中，使用具备网络增强的c3.4xlarge，Aerospike可以获得21.5万的TPS。
鉴于同等价格的性能差异，对比PV实例，我们以后的测试将只是用HVM类型。
步骤3：Use PlacementGroups
Placement Groups是同一个Availability Zone中实例组成的逻辑组，在Amazon Virtual Private Cloud（VPC）中使用Use Placement Group允许应用程序低延时共享资源，完全平分10 Gbps网络。
我们使用Placement Groups来最大化性能，同时VPC是HVM实例的首要使用前提。
步骤4：Test Tenancy
我们分别测试了专用租用（dedicated tenancy）和共享租用（shared tenancy），在没有发现明显的差别后，我们果断的选择了共享租用。
步骤5：最小化CPUStealing
在AWS上运行应用程序最大的隐患就是计算资源不可预知性，当CPU被过度使用时，比如一个线程突然间占用了太多的CPU，EC2则会结束这个线程的时间片。同时，在下一个时间片，Amazon只会给它分配较少的资源。这会导致应用程序吞吐量的跌宕起伏，这一点可以通过控制应用线程CPU。这样一来，我们就可以保证应用程序拥有更稳定的吞吐率。
在我们的测试中，Aerospike完全可以避免CPU过用。这将给我们带来可预知的性能，即使重度负载时，应用程序也很少受到CPU窃取监视影响（从0.2到0.7）。
步骤6：网络
在实例类型、VN、Placement Groups、租用和调谐选定后，我们仍然不能确定TPS受限方面。着眼实例，我们发现系统因为单核上的interrupt（中断）处理仍然存在瓶颈。每个NIC看起来只提供一个interrupt队列，默认绑定到一个单核心。因此，我们需要一个更灵活的解决方案，我们尝试了四种方法：
1. IRQ Distribution：我们尝试强迫系统将irq分布到多个核心上（disable irqbalance + echo ffff > *smp_affinity），而随后就发现它被绑定到一个独立的核心上。因此，一个独立的irq不能在多个核心上进行分配。
2. Interrupt Coalescing：在EC2上，Interrupt Coalescing对CPU利用率有些许提升，但是没有转化为更好的处理。
3. More NICs：在测试了这两个途径后，Elastic Network Interfaces（ENI）无疑是下一个必经之路。ENI让用户可以给实例增加多个（虚拟）NIC。单一的NIC峰值在25万TPS左右，增加多个接口可以增加程序的响应性，在两个实例上配置4接口和4客户端，我们可以在单c3.8xlarge实例上获得96万的TPS。通过确保每个客户端都推送到专用接口，从而可以利用所有的NIC和CPU。同时，使用具备私有IP的ENI并不会增加花费。
4. Receive Packet Steering：另一个简单的途径是使用RPS（“echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus”）将irp分配给多核心。这将避免使用多 NICs/ENIs，同时还避免了管理上的复杂度，并带来多ENI差不多的TPS。配置RPS的单NIC可以将TPS推到80万，通过跨4个核心的interrupt。
在测试过不同组合的NICs和RPS后， 通过一些Aerospike调优（比如适当的调整服务线程配置），我们可以达到非常高的性能——5个客户端（C3.2xlarge）加一个运行在C3.8xlarge上的单节点Aerospike集群可以达到百万的TPS，而花费仅仅是1.68美元每小时。
** DI = 按需实例
** RI = 预留实例
** All则是单实例给定类型的成本分析，3年和1年预留实例term计算都使用了重度负载（100%利用率）
NB：这些实例有时候体现着性能的好坏，这些数字都是一个月以上运行得出的结果。
* Core Bottleneck：我们尝试多种不同的NIC和RPS组合，但通常情况下会存在一个大量的%hi，同时会有个1核心被阻塞，峰值期间CPU利用率只有50%。
总结
以上解决方案体现了Amazon EC2已经可作为高性能数据库的一个选择，在AWS上使用Aerospike你可以花费1.68美元每小时的价格获得百万TPS。
使用AWS Marketplace在VPC中来设置一个基于c3.8xlarge实例Aerospike HVM，并将之作为一个服务器。使用一个AWS Marketplace。 为服务器实例搭载4个额外的ENI，没必要部署更多的Elastic IP。 运行afterburner.sh（cd /opt/aerospike/bin; sudo ./afterburner.sh）来最优每个Aerospike上的线程数量 使用AWS Marketplace来设置5个Aerospike c3.2xlarge实例，将这些使用了相同HVM和VPC的实例作为客户端，同时它们被布置在相同的Placement Group中作为服务器。 保证security group拥有3000-3003 TCP Port用于节点间的通信，同时为了使用AMC，TCP Port 8081需要对互联网开放。 给内存命名空间分配54GB的RAM（c3.8xlarge拥有60GB） 开启Aerospike服务器 通过Java基准客户端来加载数据 cd <java client>/benchmarks<br>./run_benchmarks-z 40 -n test -w I -o S:10 -b 10 -l 23 -k 10000000 -latency 5,1 -h YOUR_AWS_INTERNAL_IP 使用100%的读负载来运行服务器，为每个客户端指配独立ENI上的私有IP。 cd <javaclient>/benchmarks<br>./run_benchmarks -z 40 -n test -w RU,100 -o S:10 -b 10 -l 23 -k 10000000 -latency 5,1 -h YOUR_AWS_INTERNAL_IP 通过5个客户端，你可以获得百万TPS。
但是这仅仅是第一步，在下一篇文章中，我们将继续评估 4个Amazon实例价格性能比。到时候，我们将在内存中使用1个4节点Aerospike集群，同时将加载5个不同的读写负载。
原文链接：http://highscalability.com/blog/2014/8/18/1-aerospike-server-x-1-amazon-ec2-instance-1-million-tps-for.html
如您需要了解AWS最新资讯或是技术文档可访问AWS中文技术社区；如您有更多的疑问请在AWS技术论坛提出，稍后会有专家进行答疑。
订阅“AWS中文技术社区”微信公众号，实时掌握AWS技术及产品消息！
AWS中文技术社区为广大开发者提供了一个Amazon Web Service技术交流平台，推送AWS最新资讯、技术视频、技术文档、精彩技术博文等相关精彩内容，更有AWS社区专家与您直接沟通交流！快加入AWS中文技术社区，更快更好的了解AWS云计算技术。
（ 译者/薛童阳 责编/王玉平）