0

I have a socket.io server that powers a multiplayer browser game. The separate ongoing matches are stored inside a single object in-memory on the server-side:

const matches = {};

When a player creates a match, I add a new unique key to this object for tracking information about that particular game. So when players make a move, I do something like this (simplified for example code):

matches[uniqueKeyForMatch] = newValidatedMatchState;

--where newValidatedMatchState is a large tree of data describing this particular match. "Large" in this case meaning in total its various sub-dictionaries and sub-arrays contain several hundred individual pieces of numerical, boolean, and string data. Around 200-800 individual pieces of data like 5 or "some text", per match.

What I'm wondering is, if I have 100 concurrent matches, can the matches object store that much data efficiently? From this question I see there is some limitation, but I'm not sure what else I could really do other than literally have two variables like matches1 and matches2 and split the data between them. Are there more efficient ways of doing this?

temporary_user_name
  • 35,956
  • 47
  • 141
  • 220
  • You could start storing matches in a redis db, and just use the `uniqueKeyForMatch` as the redis key. – Ameer Jul 26 '21 at 23:09
  • 1
    That's a totally valid idea! I'm just new enough to this that I don't really know at what point that's necessary. I'm trying to avoid premature optimization but also trying to avoid writing code that's just outright doomed to fail from the first. (I also don't know if using redis would introduce more latency.) – temporary_user_name Jul 26 '21 at 23:10

1 Answers1

3

As mentioned in that other question, it's not really an issue. Realistically you'll run out of memory before you hit any other kind of limit. Storing a few hundred/thousand matches doesn't sound like an issue though.

Should your matches be more a kind of persistent data you want to store for a longer period, you'd start storing your matches in files or databases.

Should storing it in databases not fit your needs, or your application just gets too much traffic that the databases can't keep up, split up your application. Have multiple game servers. Your "main server" would just tell the users "your game is available at <server1>".

Also, you might find Map interesting, a better key-value storage object than regular JS objects.

Kelvin Schoofs
  • 8,323
  • 1
  • 12
  • 31
  • As a fun experiment, try this in your REPL: ```arr=[]; obj={}; for (let i=0; i<1e7; i++) { arr.push(`ArrayValue${i}`); obj[i] = `ObjectValue${i}`; }```. That'll create both an array and an object with **10 million** unique values. All that, and my Node process barely hits 1.5 GB RAM. You might underestimate how much memory you're actually using. _of course, doing heavy calculations on 10 million values is another thing._ – Kelvin Schoofs Jul 26 '21 at 23:18