亚马逊提现到pingpong延迟

亚马逊打款之后，卖家要过1-3天才能到收款账户进行提现，之后提现到账时间，根据卖家绑定的收款方式是不同的，像是Payoneer，提现之后大概要1-2天到账，WorldFirst是2-3天左右，PingPong比较快，最快1个工作日就会到账。

拓展：

亚马逊提现手续费是看你选择哪种收货方式所决定的，主要有以下这些：

Payoneer：提现费率是12%甚至更低

World First：提现费用为1%

PingPong：提现手续费收取最高1%费率

Lianlian Pay：提现费率仅需07%

亚马逊全球收款：费率低至04%，最高为09%。

AWS即Amazon Web Services，是亚马逊（Amazon）公司的云计算IaaS和PaaS平台服务。AWS面向用户提供包括弹性计算、存储、资料库、应用程式在内的一整套云计算服务，能够帮助企业降低IT投入成本和维护成本。

AWS提供了一整套基础设施和应用程式服务，使几乎能够在云中运行一切应用程式：从企业应用程式和大数据项目，到社交游戏和移动应用程式。

基本介绍 中文名 ：aws 外文名 ：Amazon Web Services 程式类别 ：应用程式 项目基础 ：大数据项目 官网 ：:awsamazon// 服务介绍,分类,竞争对手,存储辞汇表, 服务介绍 很多公司选择AWS作为其IT解决方案，AWS有很多云服务，以下介绍AWS中几类比较重要的服务。 分类 计算类： EC2（Elastic Compute Cloud） 是一种弹性云计算服务，可为用户提供弹性可变的计算容量，通常用户可以创建和管理多个虚拟机，在虚拟机上部署自己的业务，虚拟机的计算能力（CPU、记忆体等）可以根据业务需求随时调整。 Elastic IP Addresses（弹性IP位址） – 弹性IP位址是为动态云计算设计的静态IP位址。一个弹性IP位址是和你的账户相关，而不是和你的一个特定实例相关。不像传统的静态IP位址，弹性IP位址可以通过重新匹配你的共有IP位址到你账户任意的实例，从而让你可以忽略实例或者可用区域的错误。 连线本质上是通过NAT1:1的匹配每个Elastic IP和Private IP。 Elastic MapReduce ：EMR采用运行在亚马逊EC2和S3的托管Hadoop框架上。以立即获得满足需要的计算能力，例如网页索引、数据挖掘等数据密集型任务，轻松、经济地处理海量数据，不用担心对Hadoop集群耗时的设定、管理或调优。 AS（Auto Scaling）自动伸缩服务 ：允许用户根据需要控制亚马逊EC2自动扩大或减小计算能力。用户利用AS可以无缝地增加EC2的实例数量，以保证使用高峰期的性能，也可以在需求停滞时自动减少以降低成本。AS特别适合那些需求按小时、天或周规律变化的应用程式。 AS由亚马逊CloudWatch控制，并且用户不必支付CloudWatch以外的其他服务费用。 ELB (Elastic Load Balancing)弹性负载平衡 ：自动将入口流量分配到多个亚马逊EC2实例上。弹性负载平衡在实例池中不断检测不正常的实例，并自动引导路由流量到正常的实例上，直到不正常的实例恢复正常。客户可以在单一的数据中心进行负载平衡，更可以在跨中心的套用上获得相同的功能。 兼容IPv6，数据来自于CloudWatch 部署&管理类：

ACW (Amazon CloudWatch)云监控服务： 监控亚马逊自身提供的云资源以及在云上运行的应用程式。提供可视化监测，并且可以利用API调用进一步处理监控的数据。 Amazon WorkSpaces： 是一种虚拟桌面服务，托管在Amazon的云中。用户可以选择任何终端设备（如笔记本电脑、iPad、Kindle Fire或Android平板电脑）访问 Amazon WorkSpaces，获得与传统办公桌面一样的使用体验，更能享受节约设备成本、保证个人数据安全、随时随地办公等便利。 网路类：

R53（Amazon Route 53）亚马逊53号路由： Domain Name System web service(网路域名服务)。提供从基础设施（EC2实例，ELB，或者S3）到IP位址的映射。 VPC (Virtual Private Cloud)虚拟私有云： 在亚马逊公有云之上创建一个私有的，隔离的云。可以像在自己的数据中心一样定义VPC的拓扑结构。可以和公司现有的数据中心互通。可以利用NAT使得子网不暴漏区域网路IP，公用一个IP位址与外界通讯。通过NAT设定访问控制，保护数据安全性。 存储类： S3 (Simple Storage Service) ： 亚马逊简单存储服务（S3）是一种网路存储服务，可为用户提供持久性、高可用性的存储。用户可以将本地存储迁移到Amazon S3，利用 Amazon S3 的扩展性和按使用付费的优势，应对业务规模扩大而增加的存储需求，使可伸缩的网路计算更易于开发。 EBS (Elastic Block Store)弹性数据块存储： EBS卷是独立于实例的存储，可作为一个设备动态连线到运行着的亚马逊EC2实例上。EBS特别适合于单独需要一个资料库、档案系统、或访问原始块存储的应用程式。 套用服务类： SQS (Simple Queue Service)简单讯息伫列服务： 提供讯息存储伫列，使讯息可以在计算机之间传递，在执行不同任务的分散式套用组件之间轻松的转移数据，既不会丢失信息，也不要求每个组件都保持可用。SQS可以与亚马逊EC2和其他AWS的基础设施网路服务紧密结合在一起，方便地建立自动化的工作流程。SQS以网路服务的形式运行，对外发布一个web讯息框架。Inter中任何计算机都可以添加或阅读讯息，而不必安装任何软体或配置特殊的防火墙。使用SQS的套用组件可以独立运行，不需要在同一网路中使用相同的技术开发，也不必在同一时间运行。 SNS (Simple Notification Service)简单通知服务： 在云中安装、处理或传送通知。它为开发人员提供了一种从应用程式发布讯息，并立即传送给订阅者或其他应用程式的能力，用于创建通知某应用程式（或客户）某方面的主题。客户订阅这些主题，并使用客户选定的通信协定（例如，HTTP，电子邮件等）发布讯息。亚马逊SNS的潜在用途包括监控，工作流系统，时间敏感的信息更新，移动套用等等。 资料库类： SDB (Amazon SimpleDB)简单资料库： 非关系型数据存储服务 RDS (Relational Database Service)： 是一种基于云的关系型资料库服务，用户可以在云中配置、操作和扩展关系资料库。Amazon RDS 支持 MySQL、Oracle、Microsoft SQL Server 或 PostgreSQL 等关系型资料库。用户无需本地维护资料库，由Amazon RDS为用户管理。 支付类： FPS (Flexible Payments Service)灵活支付服务

ADP (Amazon DevPay)亚马逊支付设计 内容交付类： CloudFront 云前 ：整合亚马逊其他云服务产品，完成高效快速的分散式内容互动。 人工服务类： AMT (Amazon Mechanical Turk)机械的土耳其人： “机械的土耳其人”一词来源：这个名字源自于臭名远扬的能下象棋的“自动装置”，它是匈牙利男爵沃尔夫冈·冯·肯佩伦（Wolfgang Von Kempelen）1770年建造的。这个木制机器外形像一个坐在大机箱前的土耳其魔法师，它能自动而快速地下象棋，用复杂的齿轮和杠杆系统来移动棋子。在维也纳皇宫的首次表演中，它就迅速击败了对手Cobenzl伯爵，让在场的皇室成员看得十分高兴。从此关于这个惊人聪明的机器人迅速闻名于世，于是肯佩伦带着它在欧洲各地表演，击败了一系列著名的挑战者，包括拿破仑和班杰明·富兰克林。直到几年之后，这个骗局才被揭穿。原来机箱里藏了一名象棋大师，他用一个磁铁系统来跟踪对手的举动并移动自己的棋子，这个人实际是在 模拟一种人工智慧 。 虽然计算技术不断发展，但仍有很多事情人类做的比计算机更有效，比如确定照片或视频中的对象，执行重复数据的删除，抄录音频资料或研究数据的细节。一般来说，完成这样的任务通常需要雇用大量临时工人（这是耗时、昂贵和难以企及的），或者干脆没法完成。 亚马逊机械的土耳其人（AMT）完成的是一种类似模拟人工智慧的业务，它把人“藏”在一个软体程式中，用他们执行电脑不太善于完成的任务。例如假设程式设计师在写一个套用软体程式，其中有一个步骤是识别数字照片中的建筑物——这个任务会让电脑为难，但由人去做却很容易。这位程式设计师在用AMT服务时，可以编写几行简单的原始码，从而获取必要的情报。在该程式运行到某个指定时刻，在亚马逊公司的Turk网站上会自动贴出一个关于“由人执行任务”的要求，而人们会争着完成这项任务，以换取程式设计师设定的报酬。依据亚马逊公司在其网站上的解释，AMT表明人与电脑之间不寻常的颠倒关系：“当我们想到人与电脑的接口时，我们通常认为人是提出要完成的任务的一方，而电脑是完成运算任务并提供结果的一方。假使这个过程倒过来，由电脑程式要求人完成这个任务并返回结果，那又会如何呢？Mechanical Turk就是这么做的，它把人的行为和判断变成了软体程式中的功能。不是电脑为我们工作，而是我们为电脑工作。" 基于以上的弹性计算、存储、资料库、应用程式服务组合，AWS可以为企业提供完整的IT业务解决方案。最关键的是，AWS是按需使用、即用即付的模式，能够灵活应对企业快速多变的IT需求。 竞争对手 AWS目录服务 vs Azure AD

亚马逊的最新目录服务和Azure AD（微软的云目录）展开竞争。Azure AD能够很好地与其他Windows产品协同工作。单点登录功能意味着用户登录一次就可获得支持AD的套用的许可。 相比亚马逊的服务，微软的服务产品还更好地集成了第三方工具，例如Salesforce和Box。因为微软的目录服务是很早就出现的功能，能够与更多的管理工具集成。 亚马逊一直在努力向企业领域发展。新目录填补了明显的空白，帮助企业更有效地连线AWS和微软。虽然亚马逊的云目录达不到微软目录的当前水平，但随着云市场的继续发展预计将获得更多的功能。 存储辞汇表 AWS数据存储服务辞汇表 Aurora: 亚马逊Aurora是一个与MySQL兼容的关系型资料库，而MySQL是一个从结构化查询语言（SQL）衍生出来的流行开源资料库管理系统。用户可以通过亚马逊关系型资料库服务来管理Aurora的配置、打补丁、备份和恢复等。Aurora可自动扩展，可对传输过程中的数据进行加密。 资料库迁移服务：AWS资料库迁移服务可让企业用户在不同云之间或内部资源之间进行资料库迁移。资料库迁移服务不仅可作为AWS云的一个网关，它还允许非AWS资料库之间的同质迁移，并支持大部分的常用资料库。在迁移过程中，源资料库可保持正常运行，从而减少了停机时间。 DynamoDB: 亚马逊DynamoDB是一个专为满足低延迟和高可扩展性需求而设计的托管NoSQL资料库服务。DynamoDB支持文档和key-value存储模式。其高性能和灵活性特点令其特别适合于移动、网路、游戏以及物联网等套用。 ElastiCache：亚马逊ElastiCache是一个AWS托管的快取服务，它遵循开源Memcached系统，可减轻资料库运行负载和加快套用运行。 弹性块存储（EBS）：亚马逊弹性块存储可用于弹性计算云（EC2）实例的高可用性块级存储系统。它最适用于存储永久型数据，而不是动态数据。AWS用户可以先选择一个EBS存储卷类型和容量，然后将其连线到一个EC2实例。存储卷的副本可以保存为快照。 Glacier：亚马逊Glacier是一个“冷”存储服务，它可存储不常被访问的数据，从而作为其他AWS数据存储选项的一个更廉价的替代存储选项。 Import/Export Snowball：亚马逊Import/Export Snowball是一种物理传输设备。AWS可使用它来存储内部的海量数据。然后，AWS在用户返回该设备后可导入数据。反之，该设备也可用于AWS向用户导出数据。Snowball存储设备最多可传输50TB数据。 Redshift：亚马逊Redshift是一个完全托管的AWS数据仓库。Redshift可连线基于SQL的客户端和商业智慧型工具。Redshift提供快速的查询与I/O性能，这使得它特别适用于大数据分析套用。 关系型资料库服务（RDS）：亚马逊RDS提供了多种资料库引擎选项以帮助用户对关系型资料库进行迁移、备份和恢复等操作。使用中的代码和应用程式以及现有资料库都转移至RDS。RDS可自动完成打补丁和资料库软体备份以便数据恢复。 简单存储服务（S3）：亚马逊S3是一个可扩展的对象存储服务。AWS用户可以通过网路接口在网路的任意位置存储和检索数据，且只需为所使用的存储资源支付费用。S3提供了多个存储类，并可与各种亚马逊云服务协同运行。 存储网关：AWS存储网关连线了本地设备和基于AWS的存储资源，这使用户能够充分利用云的可扩展性和价格优势，同时还能继续运行本地工作负载。

15天。当用户的账户余额不足时，将不再继续创建新的收费项，AWSPaaS云实例会自动停止，节约不必要的开销。在服务逾期15天内AWS会继续为签署年度合约的PaaS实例垫付必要的资源费用，逾期15天将自动销毁用户的所有资源和数据，也就是停账号。亚马逊AWS（AmazonWebServices（AWS））是亚马逊提供的专业云计算服务，于2006年推出，以Web服务的形式向企业提供IT基础设施服务，通常称为云计算。

本文由Donny译自 3scalecom 的 《How to load test & tune performance on your API》

这几年API的作用不断演化，以前API还只是用来做内部系统之间的集成点，但现在API已成为一个公司的核心系统，一个构建于Web和移动端应用之上的核心系统。

当API仅只用来处理后台的任务（例如生成报告），那么性能差点也不是问题。但是如今API慢慢地发展成为连接服务与终端用户的核心纽带。这种关键性的角色变化表明了一个重要的观点：那就是API的性能真的很重要。

如果API数据源响应快，前端的应用程序的设计好点或差点影响不大，要是响应慢如蜗牛，前端的设计再出色也是然并卵。现在我们的客户端应用展示的数据源可能都是来自多个API响应内容的聚合，性能对这种微服务构架来说真的非常重要。

可以毫不夸张的说出色的性能就是你API提供的最好功能。我们知道向目标改进的唯一正确的方法就是找到问题的关键点，或者叫关键路径，并不断迭代测量和调整你的架构系统，直到系统达到预定的目标。对于API来说，测量和提高性能的过程就是负载与压力测试的过程。

本文将重点介绍如何对你的API进行负载压力测试。我们会以一个简单的、未测过的例子开始，然后再添加一个访问控制层，要确保一切都经过严格测试，做好处理真实流量的准备工作。OK，开始吧！

首先我们要明确要测试什么，可以是对你所有的API接口，或者是对单个API接口，或是对需要排除故障或改进的API接口的常规测试。

本文的其部分，我们将使用一个示例API。这是一个棋牌类游戏的Nodejs API。它有三个API接口：

/question – 返回一个随机黑牌

/answer – 返回一个随机白牌

/pick – 返回一对随机的问题与答案

你测试用的负荷情况越和真实环境的越类似，你的负载测试就越有用。如果你不知道实际流量有多少或者你不知道负载在所有接口上是否都一致，那么就算你知道你的API可以保持400 请求/秒的吞吐量也没啥鸟用。

所以，你应该先从收集你API的使用数据开始。你可以直接从你的API服务日志或者从其他你在用的应用性能工具（例如New Relic）中获取数据。在对你的API进行第一次测试之前，你应该对以下问题做到心中有数：

（1）每秒请求数的平均吞吐量（Average throughput in requests per second）

（2）峰值吞吐量（您在某段时间内获得的最大流量是多少？）（Peak throughput）

（3）API各接口的吞吐量分布情况（有没有一些接口的流量远超其他接口？）

（4）用户的吞吐量分布情况（少数用户产生大多数的流量，或者是更均匀分布？）

另外还需要考虑的一个关键点是，在测试期间将要模拟的流量会是怎样的，主要考虑点是：

（1）重复负载生成（Repetitive load generation）

（2）模拟流量模式

（3）真实流量

通常我们最好以最简单的方法开始测试，然后逐步演化到更为接近真实环境的测试。我们可以先用重复负载生成来做为API接口的第一个测试，这样不仅可以验证我们的测试环境是否稳定，更重要的是可以让我们找到API能承受的最大吞吐量，这样我们就可以知道API可以达到的性能上限是多少。

找到你的API性能上限值后，你就可以开始考虑如何将你的生成的测试流量塑造得更接近真实环境。使用真实流量来测试是最理想的，但实际操作不太可行。要模拟真实流量比较难，也太花时间。所以我们有一个折中点的方法：先研究你的流量分析数据，并做一个简单的概率模拟。比如你有100个API接口（提示：原文endpoint在这里我译为接口，翻译成端点也可以，不过译成接口感觉更容易理解），你检查了上个月的使用情况，发现80%的流量来自20个接口，其中3个接口占用了50%的流量。那么你就可以创建一个遵循这种概率的请求列表，并提供给你的负载测试工具。这样做就相对快多了，并且它相对比较接近你真实负载，可以显示出你实际环境中可能遇到的问题。

最后，如果你拿到你要测试的API的真实访问日志，你就可以用它们来做最接近客观现实的测试。我们待会儿要讨论的大部分负载测试工具，都是接收一个请求列表作为输入文件。你可以用你的访问日志，稍微做一个格式调整就可以匹配每个测试工具所需的格式。搞定这个你就可以在测试环境中轻松重现你的生产流量。

好了，你清楚了你要测试什么鬼了，准备工作的最后一步就是配置好你的测试环境。你需要一个专用的测试环境。如果你不怕被你老板骂的话，或者比较任性，你也可以直接在你的生产环境中进行性能测试，不过出问题别说哥事先没跟你说清楚哈。

如果您已经设好一个预生产或沙箱环境，并且你的API也在上面运行了，那么你就万事俱备了。因为本文要用示例API，我们会在AWS的服务实例上设置我们的环境。

在我们的例子中，我们使用一个简单的API，不需要从磁盘读取或在内存中保存大型数据集。我们选择Linux C4large 实例就够了。

注意：我们对比过其他相似处理资源数但内存更大的AWS实例，但实际测试中内存大部分没使用，所以我们选了C4large

接下来，我们将一个配好的负载测试实例（服务器）运行起来，这只是一个运行模拟测试程序的服务器，它会通过从多个并发连接重复发送请求到我们的API服务器。你需要模拟的负载越高，机器的性能就要求越高。再次，这也是一个CPU密集型工作负载。这里我们选择具有4个虚拟核，16个 ECU的优化处理器的 c4xlarge AWS服务器

我们选择在相同的可用区内部署所有实例（API服务器与测试服务器在同一个区/机房），这样可以将外部因素对我们测试结果的影响降到最小。

我们有一个沙箱环境来运行我们的API，同时也有另一台服务器准备开始负载测试。如果这是你第一次做性能测试，你一定会想知道什么是最好的方法。在本节中，我们将会分享我们如何选择工具，同时也会介绍一下目前市面上一些公认比较好的工具。

JMeter

在人们意识当中，首当翘楚的估计是 Apache JMeter ，这是一个开源的Java程序，他关键的特性就是提供一个强大而完善的创建测试计划的GUI。测试计划由测试组件组成，测试组件定义了测试的每一个部分，例如：

（1）用来注入负载测试的线程

（2）参数化测试中使用的HTTP请求

（3）可添加侦听器，象widget测试组件那样，可以以不同的方式显示测主式结果

优点：

（1）它是功能性负载测试的最好工具。你可以设定条件来为复杂的用户流建模，还可以创建断言来验证行为。

（2）轻松模拟复杂的http请求，比如请求前的登录验证或文件上传

（3）可扩展性强，有很多社区插件可以修改或扩展内置的行为

（4）开源并且免费

缺点：

（1）GUI学习曲线陡峭，一大堆的选项，在你运行第一个测试之前你得了解大量的概念。

（2）测试高负载时，操作步骤很麻烦。你需要先使用GUI工具来生成XML测试计划，然后在非GUI模式下导入测试计划运行测试，因为GUI会消耗掉本用于生成负载的大量资源。你还需要注意所有的侦听器（收集数据与展示测量的组件）哪些要被禁用或启用，因为它们也很耗资源。测试结束后后，你需要将原始结果数据导入GUI以才能查看结果。

（3）如果你的目标是测试一段时间内的持续吞吐量（例如在60秒内每秒请求1000次），那么很难找到正确的并发线程数量和计时器来求出一个比较稳定的数值。

JMeter只是我们在开始测试时用的工具，我们很快开始寻找其他替代方案。原因是，如果你的目标是在Web应用上压力测试复杂的用户流，那么JMeter可能是最好的工具，但如果你只是需要在一些HTTP API接口上进行性能测试，那用它就是杀鸡用牛刀了。

Wrk

Wrk 是一款和传统的 Apache Benchmark （最初用来做Apache服务器的测试工具）非常相似的工具。wrk和ab完全不同于JMeter：

（1）一切都是可以通过命令行工具配置和执行的。

（2）配置少但强大，只有基本生成HTTP负载的必要几项配置

（3）性能强悍

然而，和传统ab工具相比还是有几个优势的地方，主要是：

（1）多线程，所以能利用多核处理器的优势，更容易生成更高的负载

（2）利用Lua脚本很容易进行扩展默认的行为

不好的地方，主要是生成的默认报告在内容与格式上都受到限制（仅文本，无绘图）。当你的目标是找到你的API可以处理的最大负载量，那么wrk是你最佳选择工具。wrk用起来很快就可以上手。

Vegeta

Vegeta 是一款开源命令行工具，但它采用的方式不同于我们以前所见的工具。它专注于如何达到与维持每秒请求数速率。也就是说它侧重在测试支撑每秒X次请求时API会有怎样的服务行为，当你有实际的数据或对你将要达到的峰值流量有个估算时就非常有用，你可以用于验证你的API是否能满足你的需求。

SaaS 工具

正如你之前所看到的，运行一个简单的负载测试需要准备好配置环境。最近有些产品提供负载测试服务。我们试过两个， Loaderio 和 Blazemeter （话外：阿里也有性能测试工具 PTS ，老外估计没试过）。

注意：我们只试了这两个工具的免费版，所以得到的测试结果仅适用于免费版的限定。

Blazemeter

这个产品和我们前面提到的JMeter一样有同样的毛病：如果你只需要用在高负载测试，你需要在GUI界面上创建测试计划，然后在另一个运行非GUI模式的JMeter中导入这些计划。Blazemeter允许你上传JMeter的测试计划到他们的云端并运行，但可惜的是免费版只能设置50个并发用户。

Loaderio

它是一款 SendGrid 出品的简单而强大的云负载测试服务工具。它有你所需要的功能和漂亮的可视报告。 Loaderio 的免费版还是不错的，每秒最多可以有10000次请求的吞吐量，你基本上就可以用它来运行一个真实的负载测试。

我们推荐使用多个工具，以便可以多重检查我们的测试结果，不同的工具有不同的功能与方法，可以更多方面地反映测试结果。

我们先尝试找到我们的API可以承受的最大吞吐量。在这个吞吐量下，我们的API服务达到最大CPU利用率，同时不会返回任何错误或超时。这个吞吐量就可作为我们后面测试要用的每秒请求数。

同样，重要的是要注意到：CPU是限制因素之一，但你也还必须清楚地知道哪些资源会成为你API的性能瓶颈。

我们有必要在API服务器上安装一些工具，以便我们在测试过程中监控资源的利用率情况。我们使用  Keymetricsio  和  PM2  模块。

我们的Nodejs应用运行了一个非常简单的HTTP 服务。Nodejs是单线程设计的，但为了利用c4large AWS实例中提供的双核，我们使用PM2的集群功能来运行应用程序的两个工作进程。

由于我们的API是完全无状态的，所以很容易使用PM2的 核心集群模块（PM2在内部直接使用）。PM2提供的集群功能提供了不错的快捷命令来start/stop/reload应用程序，也可以监控进程。

我们先使用Loaderio对API进行测试。以下是持续30秒，每秒10,000次请求的测试结果，10000次请求是Loaderio免费版中允许的最大吞吐量。

在测试期间，我们观察到API服务器的CPU处理器在测试期间只有几次达到100％的容量。

这表示我们的API可能还可以处理更高的吞吐量。我们接下来通过运行wrk进行第二次测试证实了这一点。我们的目标就是要将我们的API服务器性能推到极限。

wrk -t 4 -c 1000 -d 60 --latency --timeout 3s http://api-server/questions

这里是我们对这个测试做了多次重复测试的结果：

Running 1m test @ http://api-server/question

4 threads and 1000 connections

Thread Stats Avg Stdev Max +/- Stdev

Latency 6223ms 3085ms 135s 9939%

Req/Sec 407k 35761 527k 9429%

Latency Distribution

50% 6004ms

75% 6385ms

90% 6417ms

99% 7586ms

972482 requests in 100m, 18989MB read

Requests/sec: 1620604

Transfer/sec: 316MB

结果表明，我们的预感被证实：它达到16,206请求/秒，同时保持合理的延迟，第99百分位只有7586毫秒。 我们将这作为我们的基准最大吞吐量，因为这一次我们看到了API服务器的最大容量处理能力：

我们刚看到用一个简单的方式来找出你的API可承受的最大流量负载，同时在这过程中我们介绍并讨论了我们看到的一些工具。

请继续关注本文的第二部分，我们将介绍如何控制流量，不要让随随便便一个客户端就可以轻松搞跨您的API。 我们将展示如何通过在架构前端添加代理来确保我们的API的性能不受影响。

本文译自： How to load test & tune performance on your API