API：HTTP restful – JSON
地理位置：欧洲,美国
客户：移动设备
听起来你问的是两个不同的问题：> API服务器的性能特征是什么？最有用的表达方式是：在响应时间超过可接受的水平之前,它可以服务多少并发用户？
>您的客户端设备的性能体验是什么？
我鼓励你把这两个问题分开,然后独立测试.在3G上运行的设备将难以产生足够的负载来对配置良好的Web服务器施加压力,并且在全球范围内调试数千个负载测试节点通常不具成本效益.此外,一旦流量到达您的Web服务器,它不应该真正关心它是来自同一个城市,国家或大陆,还是来自移动设备或PC或负载测试服务器.
因此,我会使用您喜欢的任何负载测试工具来测试Web API的性能. Apache JMeter是免费的,但有一点学习曲线;但是,它可以从几个云提供商处获得,它允许您进行测试并从不同的大陆运行它们.谷歌“Jmeter云”了解更多细节.
如果性能是一个关键问题,那么您可能希望拥有一个连续的测试机制,您可以在一周左右的时间内对代码进行性能测试,并随时进行优化 – 将优化留到项目的最后通常是相当危险的. .
接下来的问题是“好的,所以我知道我的API服务器可以提供1000个并发请求,平均响应时间<1秒”(或其他) - 这如何转化为最终用户体验？ 一旦你非常清楚你的网络服务器不是瓶颈,攻击它是有道理的 – 因为你为超越这一点优化性能而做出的大多数决定都非常重要. 从逻辑上讲,如果您知道您的Web服务器在某个级别响应,则最终用户性能会受到网络延迟和吞吐量的影响.延迟通常通过ping时间的粗略统计来衡量：网络数据包在客户端和服务器之间传输需要多长时间？如果不重新审视整个托管策略,很难或无法改善ping时间;它取决于光速,托管服务器场与客户端和服务器之间的许多其他网段之间的连接. 吞吐量通常以每秒字节数来衡量.通常,这是您可以影响的事情 – 例如,通过使用压缩等使您的API更简洁. 3G设备通常具有相对较差的网络延迟特性,但在正常情况下吞吐量相当不错.然而,有许多情况会影响延迟和吞吐量,这些都是完全不可预测的 – 繁忙的位置是典型的例子：一个装满3G设备的足球场意味着个人用户通常连接不良. 测试这很难.我将其分解为测试3G设备,并测试地理变化.为了测试3G设备的性能特征,我将在专用测试套件(可能基于JMeter)前使用带宽限制器模拟网络状况. 拼图的最后部分可能很昂贵 – 有专业公司可以测试来自世界各地的网络性能.他们在世界各地都有节点,可以在那里执行测试脚本;他们经常为您编写脚本,并为您提供运行和测量测试的Web界面.我过去使用过Keynote,发现它们非常好.这种测试很昂贵,所以我只在项目结束时使用它,一旦我排除了所有其他性能方面的考虑.