Most data that people can change are only authorized to be cached on the CDN edge close to you for 5 seconds, usually. Some things which cannot change over time (game archives for months in the past, the daily puzzle, etc.) are cached for longer periods and will see a greater improvement from the cache. Most CDN cache responses are less than 30ms; most ping rates (as a theoretical "fastest time") from Australia to California are around 200ms. Similar from a lot of Europe. Even if the CDN has valid cached data, it must revalidate the data after that 5 second period, and though it has an optimized path to our server that is still limited to the speed of light plus our server response time (usually 1ms unless the data have changed).
api.chess.com performance comments
Sort:
Oct 2, 2018
0
#3
OK, so that very rough test was ~2.5 requests/second. Agree 200+ms "ping time" for trans-Pacific requests would max out at 5 requests/second. Not enough data for bandwidth to matter. Not setting any speed records but not too bad either.
I have one script that I must stare at some more; last time I tried to optimise it I broke it, but re-ordering my requests and caching a little more on my side should be able to improve it.
Of course 5s caching at the CDN would not be enough for my run of 300 in the simple profile lookups I was doing, as with 300 names 5s would have passed before I hit with a repeat name.
I'm impressed with the little Raspberry Pi. Of course I suppose it's a racehorse compared to a VAX 11/780. 
For a very informal test, I ran a script that checks currently just shy of 300 accounts to see if any are closed. Very little disk I/O, just read the list. From api.chess.com, fetch the profile for each account to check the current status.
My two tests used the same Wi-Fi(*) access to the same ADSL2+ modem to the same ISP (no VPNs this time around) and from all the way across the Pacific (although in case anything is cached on first lookup, I ran a warm-up).
I ran tests on a Rasperry Pi 3B+ (ARM quad-core 1.4Ghz processor) and an older MacBook AIr (i7 processor of some vintage, dual-core, 2Ghz).
No significant difference in wall-clock time, as expected. My current belief remains that my scripts wait on responses from api.chess.com, and for any substantial performance improvement at my end I am going to have to cache more aggressively.
Wall clock time: ~2 minutes
User CPU: ~7s (Raspberry Pi); ~2s (MacBook Air)
Kernel CPU: .01-.02s in favour of the MacBook Air. Totally negligible w.r.t. the wall-clock time.
The script is single threaded and waits on one response before making the next but retains a HTTP/1.1 SSL connection.
This is not a terribly rigorous test, but I was interested to see how the Raspberry Pi handled the task. (I'm considering sitting one on my desk as an "always available" desktop machine which doesn't have either fan noise or disk noise. Back in the day I ran my desktop PC diskless and with an ultra-quiet power supply; I hate computer noise. So yes, I have a neat new toy.
)
(*) The Wi-FI I don't think was the limiting factor, although it is only 2.4Ghz "N" and not 5Ghz "ac". I am making do with a second hand ADSL2+ modem I thought for a few weeks, but the Australian National Broadband Network roll-out has been delayed a year where I live. When I used 5Ghz "N" all I noticed was less reported signal strength. What I honestly care about is what content distribution networks make available locally, and after that international bandwidth.