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