I’m extremely surprised you are throwing more hardware at MSSQL instead of moving to PostgreSQL which is arguably the better database in 2022.
Not that updating the hardware solutions isn’t a good thing, but PostgreSQL has really come a long way.
As for the struggles in perf in large-scale, streaming events in a multitude of pub/sub subscription rather than individually processing each client would probably alleviate the enormous connection pressure on the DB backends. A proper Event-driven delivery scales way better than any DB caching.
I mean we’re tick-based anyways, might as well stack those changes up and flush em to the clients. Even if it means broadcasting everything that happens in an entire system during TIDI then so be it.
Oh cool, I’ve missed that change. Also pretty neat that they’ve essentially implemented what I suggested.
Utilizing protobuf for it sounds like the right approach considering size/speed, and gRPC will surely serve them well over REST, GraphQL or similar.
I’ve never used gRPC specifically, but I might look more into it. Golang is also a nice change for the server-specific parts that can be optimized shorter-term. I doubt we’ll see a rewrite client-side to any other language. It’d take an enormous amount of time.
From the post, it doesn’t look like this is something we will see utilized for much (yet?), but I hope for the game’s sake they’ll prioritize it going forward.
I disagree on that part, GraphQL is more flexible for variations in third-party clients and also reduces versioning headaches. gRPC is fine when you control all participants in the development (CCP owned client and server in this case) but not when you are dealing with clients out of your control (third party developers). Not all third-party clients want the same structure of data for their needs, that results in wastage of over-querying, discarding and multiple queries. Sure it’s all cached, but, it complicates the client.
REST has had its day (it is over two decades old from the original paper) and the upcoming HTTP verb for QUERY (GET with bodies semantically correct) that opens up for better query handling on the server than abusing POST semantics and url mangling, and results in non-restful designs.
One size of solution does not fit all problems.
gRPC is a remote procedure calling and messaging stack
GraphQL is a data query language
Don’t you physically destroy actual non-volatile storage at end of life due to the risk of data recovery later (even many years later with better tools/techniques)? Not that I imagine it’s encrypted to begin with too, this problem is even worse for solid state storage.
We had another amd dual socket 8core cpu box in to play with but it ended up having weird hba issues so we had to rule it out.
There was also a single socket 28 core Intel box we tested - at the time EVE’s code base overran it mercilessly on cold starts. We could barely get the cluster started
Please TELL ME WHO depends on CCP to get it right ???
Since when has any spreadsheet CCP published to the forums been correct WITHOUT a player asking for it to be corrected ? The MER is NEVER correct without an update post…
You would think internet spreadships would be easy but it seems CCP never listen.
Those redundant network cables posted in the first few posts of this BS topic are not wires - those are Long Term players who gave up - It’s that simple.
Speak with your CSM CCP - They care not for BS posts like this but about the community.
Wanting on the Eve is dying announcement that Eve was actually run on a spreadsheet, since it has rows and columns pretty much like a database and the licensing was cheaper.
