Socket.io optimization. Is it reasonable to store sessions in redis?

Question

MongoDB

Baseline:
Ubuntu TLS 14.04. 1GB RAM, 1core CPU. SSD 30GB. ($10 droplet on digitalocean).
Application MEAN + socket.io
On the main page, dynamically updated tables with player ratings. Possibility of registration, authorization, voting.
A mandatory requirement is real-time data updating for both anonymous and authorized users.
Socket session storage was implemented using standard methods i.e. in js.
Problem:
When more than 3000 users accessed the page at the same time, the server stopped coping and died.
Our actions:
1. Optimized the code, divided the functionality into several parts:
- Functional (for authorized users): likes, work with the user profile.
- Informational (for all):
ratings update.
2. Redis was used as an adapter for the socket.
Questions:
1. Is it reasonable to use Redis in this situation? What optimization methods should be applied in the first place?
2. Will users notice a gain in reading speed from RAM due to the use of Redis, or is the increase imperceptible on such small amounts of data?
3. Could MongoDB be used as a session storage, so as not to breed a "zoo" of storages?
4. How justified was it to abandon the standard way of storing sessions?

Answer 1

I don't know how useful my comment is, but I'll write it anyway. There was an application on Node using sockets (were still young and green), there was a similar problem. The problem was solved as follows - we distributed the load of the node server itself to 4 cores, which significantly increased stability (previously it worked on one due to the node architecture). And fixed bugs in the code.
Judging by your comment, I have the impression that you do not know where the bottleneck in your application is, you need to profile the code. Maybe the crash has nothing to do with sockets at all.