Sorry, it looks like my posts are getting staggered with your own. I completely understand your concerns.. I actually made a similiar post elsewhere because I thought there may be an issue. I was top 5 in one of the event with >1 min and ended up placing in top 100. While there may in fact be an issue, this is most likely just a matter of latency. Given the rubberbanding and reset schedule, the last few minutes of the event must see a ridiculous spike in activity. The server is probably just strained providing everyone with their game data.. remember that it has to send the match information too, not just the scores and point values.
They’ve likely re-prioritized the work flow so that game data takes precedence over lesser important tasks like scoring updates. If “x” is the lowest activity in the game and “z” is the spike that occurs 2% of the time when matches end, you want to optimize your infrastructure to handle “y”. If “y” mode can’t handle all of “z” mode, something has to give. Would you rather have a latency in rank values or a “Cannot Connect with Shield Servers” error at a crucial time? I think a lot of these changes occurred during the last release and they are still ironing out the wrinkles. I’ve been wondering about this ever since the hotfix was needed for the “Save game corrupted” issues last week. I could be way off base, but I was thinking this also might be the reason they decided to run an old PvE event using the legacy format for refreshes.
(Staggered again!)
first, when you finish a game, it should send the score directly to the server. not hold onto it for later. if you hold onto it, it there is a risk that the score will never show up on the server in the case that the game was closed, crashed, etc and never loaded.
the rank that you see in the map screen is likely updated when you enter the map screen, after each match, when you load the leaderboard and every x minutes if you just sit around the map screen.
there is no reason why the leaderboard is not 100% up to the second when you first load it.
That game data is being cached somewhere for sure, even webapps do this. I suspected it was on the local device because of the hacking issues they were seeing on Steam. Someone found out that token results were actually determined locally and were able to manipulate that. I believe they’ve made changes since, but even if our data were being sent immediately, there is no way it is all being reconciled and returned instantly.
First off, the data must be stored somewhere.. Unless it’s a proprietary database (which is doubtful), they are probably using a SQL or Oracle instance. The front end needs to accept the connection, transfer the data from memory on to the physical media, and move it from that cache on to a table in the database. All of that info then needs to be interpreted and tabulated.. This is almost certainly being performed on another network entirely, likely through one of Google’s datacenters. The actual boxes running the MPQ source will need to poll that raw data, do whatever magic it does, and return it. Even a beastly array that is processing hundreds of thousands of threads at once would choke unless properly throttled. I mean, look how often websites crash when too many requests are submitted at once – the end of a large event is probably akin to a DDoS attack on the server.
There is no such thing as ‘instant’ when dealing with a client/server relationship over the WAN. Too many variables and checkpoints. In times of high volume, a priority protocol has to be in place to ensure critical data is handled first, and in this case, our rank listing wouldn’t be at the top of that list. I’m not saying that some more optimization couldn’t be put into place.. but to provide that level of connectivity and service, it would cost more than is practical. Look at Blizzard – if there ever were an expert on this subject, it would be them. Yet, they launched Diablo 3 on a fail boat. They could have beefed up their org to be prepared for cataclysmic traffic, but they didn’t. Not because they were caught off guard, but because they looked at the cost, balanced the loss vs. gain, and said “tinykitty it, let them eat queues” 
To wrap these rants up, I don’t think there is an issue and I don’t think these delays are normal, but instead a result of the server prioritizing returns based on a high volume scenario. Ideally, the server could handle everything, all the time, but this is not in line with best practices and is also a pretty fail move business wise. Therefore, I don’t think there will be a major change aside from some tweaks here and there.
[On a side note, I really hope IceIX reads of this and tells us how completely wrong we are and that the delays are the results of a solar flare or something]
