XpartaMuPP performance - 0ad sends too many messages

[elexis]

While working with XpartaMuPP, I noticed that its performance should be improved. I noticed 3 problems in particular.

1. Limit update rate: Every time the host changes the game settings, a message is being sent to XpartaMuPP. Especially if one scrolls through settings with the mouse wheel (civs, map, player count, team numbers) too many (useless) updates are being sent. This should be limited to at most one message per second. The performance problem already comes apparent when testing with one host and one lobby client and only scrolling one setting once. It takes some seconds for XpartaMuPP to broadcast the messages.

2. Don't set host to not-ready: If the host changes a single setting, 3 instead of 1 message is sent. That is because if he changes the setting, all player states will be reset (even the hosts will be 'not ready'). After that the host is being set to ready automatically. This could be fixed by never setting the host to not ready.

3. Updates with no change in it: Only some settings are broadcasted to the lobby clients (players, number of players, victoryCondition, mapName, mapSize), while an update is being sent if any game setting changes. This results in many updates where nothing relevant has changed. For example currently XpartaMuPP doesn't send to the lobby which teams are setup. Despite this, it sends an update if only the teams are changed. To fix this, XpartaMuPP could keep track of the last update that was broadcasted and only send another update if something has actually changed. The same logic has been done clientside in gamesetup.js with r17943, but could certainly be done in XpartaMupp too. See also #3847 for further clientside optimizations.

[sanderd17]

Number 1 and 2 sound good. Number 3 will be easy to get it wrong, and will also make further updates harder.

[scythetwirler]

Limit update rate: I'd prefer that the number of sendGameList be throttled on the XpartaMuPP side rather than the host's. It scales better (and I doubt anyone would notice the difference if we send gameLists update at most once every two seconds or so) with more players and we don't have to worry about a rogue host modifying the js and DDoSing the bot (as much, though hopefully ejabberd will throttle those too).

2 sounds good.

3 could be tricky and I'm not sure it would be worth it.

[scythetwirler]

1. Limit update rate:

Deployed some changes locally on the server. Will see about committing if it helps.

[elexis]

Replying to scythetwirler:

Deployed some changes locally on the server. Will see about committing if it helps.

Seems to be okay besides the playerlist not showing ratings. If you click on a player it takes about 2 seconds to load which is fair enough.

[elexis]

Backlogging due to lack of progress.

[elexis]

In r19641:

Vastly reduce the number of gamelist lobby updates sent by the 0 A.D. client (by waiting 2 seconds for the gamesettings to not change before sending an update). An empty lobby with single client scrolling with the mousewheel through the skirmish maps for few seconds was sufficient to delay the server updates globally for more than 15 seconds.

Based on patch by: sbirmi Fixes #3847

[phosit]

Related to 1. #6740

[Stan]

Push back