I now had a closer look at the chat lag problem. (See Kenders Post how this can be done).
I won't say that I understand the whole procedure completely but I got a good overview.#1: Network performance?
The Disney Servers are not the problem. They deliver the chat messages fast enough.#2: Message number!
There are two servers involved in the chat. The "chat" server which delivers text messages only and the "game" server which delivers seemingly all other (i.e. donations, war updates, etc...)
On startup, I see that the "game" server delivers a block of 1420
(!) messages to the game.
Inspecting the data, the oldest Message is almost exactly 3 days old.#3: Opening the Chat window and Message limit:
Here it gets a bit complicated but this is how I understood the code:
When the chat window is opened (initially), many (*) of the 1420 messages are completely processed. And only after (!) processing the messages the count is checked and the message is removed again.
(* actually 1350 of the 1420 non-chat Messages were donation messages and therefore remain untrimmed.)#4: Cause of the lag?
The lag is caused by high CPU utilization (maybe even GPU) on the client and directly related to the chat/donation activity of the squad in the last 3 days.
By the way:
The number of 1420 is actually low for our squad because we had no war in the last days and activity was probably a bit lower than usually (family demands presence on christmas, you know...)
I think that this number will often get around 3000.#5: Why did they do it?
a) Lazy coding. "It works this way, why change it?" Optimizing the chat may introduce new errors.
b) War state updates/consistency. The messages contain also info about i.e. Factory Outpost posession and other War state changes. The exact 3 day period equals the (original) time a war takes (1d scouting, 1d war, 1d cooldown).#6: How to do it better?
I understand that the programmers don't want the chat/game to miss certain messages. But they could at least strip older donation messages when they get past a certain limit. Obviously, the server already delivers a trimmed version of the message list
because there are 3 days old donationMessages but no requestMessages older than 9h. The server should not deliver donationMessages which are older than the oldest requestMessage. Filtering those redundant donationMessages on server side
should significantly reduce the message count (in my test from 1420 to 261) and therefore reduce the lag.
You could also modify the TrimMessage (see below) method but this would require an app update and is also on the wrong end (imho).
This is the (client-side) "preprocessing" Routine:StaRTS.Main.Views.UX.Squads/SquadMsgManager::TrimMessages
But: This routine skips all donation messages (basically one message per donation button press).
And: Donation messages are actually the majority (1370 of 1420) of these messages. So TrimMessages does nearly nothing.
Code: Select all
jq "[.data.result | select(.type == \"troopDonation\")] | length" <response.json
Another method to check: