Scaling for steam influx (7000 players in one hour)

[Licho1]

We would like to design a way to scale up for steam players influx. Logs from EvoRTS show that 7000 players downloaded the game in first hour.

Suggest protocol change is to only update state of objects that user interact most with. That means no global "adduser" and status changes. Post those only to people in same channel and same battle. Players from steam would not join any channel by default so this would reduce load significantly. If there are too many battles, it could be fixed by providing "filter" - user sends filter definition to uberserver and it only updates battles matching filter for the client.
It would also be great if metadata could be kept on uberserver and transmitted by it instead of relying on nightwatch extension.

In simplest implementation metadata would be a dictionary set on user and battle room objects. Client would specify what keys it wants to listen to and bots with admins would be able to set those metadata.

[abma]

imo CONNECTUSER is your friend (+ some lightweight mode which basicly is only auth and a few status messages)

spring/LobbyProtocol#19

[Licho1]

Yeah but i think its possible to tweak protocol to retain most functions (chat, list of users in battles etc). If not and you think its best to go connectuser etc .. such stuff can also be done outside of uberserver..

[gajop]

I agree with Licho on this. This should be done on the server.
I think uberserver should be changed to support a lightweight compatibility flag that would drastically reduce the type and number of messages received, and thus reduce server load.

My proposal is that supporting the lightweight mode should filter out the following commands:

• BATTLE* (battle information should be only obtained by query - add a BATTLELIST command, maybe with paging)
• CLIENTS (for some channels, JOIN command should specify whether or not all clients are listed for a channel)
• CLIENTSTATUS (should only be received for friends)
• JOINED (for some channels, see CLIENTS)
• JOIN/LEFT BATTLE (for battles that the client is not in)
• ADD/REMOVEUSER (should only be received for friends)

I'd also remove the client "CHANNELS" command or add mandatory paging to it.

All this can be simplified further to just completely filter CLIENTS and JOINED for all channels, although personally I'd only do it for large ones like #main, #zk and similar.

Once implemented (and I don't think it would take more than a week to do so) I'd give everyone 3-6 months and then make this flag mandatory (would still have to be supplied, but would be considered mandatory).

[abma]

@Licho1
i know its offtopic here, but is there a plan to let games run without autohosts (=running spring-dedicated)? with an autohost running for each battle imo there could be a bottleneck, too. 7k users = a lot of battles / spring-dedicated instances.

and yeah, light mode makes sense, but its a lot of work and very few people contribute. :-|

[Licho1]

Im going to fork server and try to implement it..
Plan for now is to keep autohosts, because i implemented quickmatch in such way (that it spawns autohosts) to make it work for other lobbies. Sadly it didnt go as planned because server side force join is out..

[abma]

@Licho1:

as long as you don't help to solve problems i can't help you. please respond to my questions in #121 and we find a solution.