It looks like you are asking two separate questions:
- What are the performance characteristics of your API server? The most useful expression is as follows: how many simultaneous users can it serve before the response time exceeds your acceptable level?
- What is the experience on your client devices?
I would advise you to separate these two problems and test them yourself. A device running over 3G will try to create enough load to emphasize a well-configured web server, and it is generally not economically feasible to enter thousands of load test nodes around the world. In addition, as soon as traffic arrives at your web server, it should not worry if it came from the same city, country or continent, or it originated from a mobile device or PC or a load testing server.
So, I would use any load testing tool that you like to test the performance of your web API. Apache JMeter is free, but has a little learning curve; however, it is available from several cloud providers, which allows you to run tests and run them from different continents. Google "Jmeter cloud" for more details.
If performance is a key issue, you probably want to have a continuous testing mode where you put your code to performance testing every week or so, and optimize when you go - optimizing the transition to the end of a project is usually rather risky ...
The next question is: “OK, so I know that my API server can handle 1000 simultaneous requests with an average response time of less than 1 second” (or something else) - how does this translate for the end user?
It only makes sense to attack this if you are really clear that your web server is not a bottleneck - because most of the decisions you make to optimize performance at this point are pretty significant.
Logically, if you know that your web server is responding at a certain level, end-user performance depends on latency and network bandwidth. Latency is usually measured by raw ping time statistics: how long does a network packet take to move between client and server? It is difficult or impossible to improve ping time without reviewing your entire hosting strategy; it depends on the speed of light, the connection between the hosting farm and dozens of other network segments between your client and server.
Bandwidth is usually measured in bytes per second. Often this is something you can influence, for example, by making your API less verbose, using compression, etc.
3G devices usually have relatively poor network latency characteristics, but pretty decent bandwidth under normal conditions. However, there are many circumstances that affect both latency and bandwidth, which are completely unpredictable - a classic example - occupied seats: a football stadium full of 3G devices means that individual users often have poor connections.
Testing is hard. I would put it into testing for 3G devices and check the geographic differences. To test the performance characteristics on a 3G device, I would simulate network conditions using bandwidth controls before a special set of tests (probably based on JMeter).
The last part of the puzzle can be expensive - there are specialized companies that can test web performance from around the world. They have nodes all over the world where they can execute test scripts; they often write scripts for you and provide a web interface for running and measuring tests. I used Keynote in the past and found that they are very good. Such testing is expensive, so I use it only at the end of the project, as soon as I excluded from consideration all other aspects of performance.