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