The session timer has probably always been there, in the background. I think it was only exposed in the UI in 2007.

Maybe, with future iterations on software.

Tranquility proper is in a datacenter just outside London.

I mix up terms sometimes, so it depends on who you are talking to and the context

SOL Server would typically be either the physical or virtual server that our code runs on. A sol node would be one instance of the application code running on the actual SOL Server

Typically we use SOL as a interchangeable term for solar system node - a windows OS based server that can run one or more in-game solar systems/services.

For TQ, all sols are physical servers, most test servers run sols as virtual machines

We’re planning a SQL only blog for a later date where we can share more info on the various configs we have going on.

The param sniffing stuff, have not gotten deep into that yet, but that’s basically where the db team is at now - sql 2022 testing and excitement - it’s got a ton of great features that’ll be useful not only to us dba’s but our data engineering team as well.

Probably never. This is a safeguard that all the all nodes involved have finished their work in moving you; this is the timeout when the other nodes can move ahead if there is no confirmation.

No.

Inserting more characters here since evidently a reply must be 5 characters or more.

Every time we have upgraded hardware or optimized software, then players have brought more pilots for the next fleet fight.

I wrote this with input from @CCP_DeNormalized and others.

There is only one VM in Tranquility proper, and that is a proxy for internal use only. Everything player-facing is running directly in top of hardware. We have tested using VMs for some of the smaller player-facing services and it worked fine run-time but we had issues starting the cluster since the nodes running on the VMs would lag behind the nodes running on hardware.

There are many VMs and pods running in the Tranquility Ecosystem, inside AWS. None of them existed at the time of Tranquility Tech III but have added since then, outside the simulation/game cluster.

My current negotiations with Ops have us at a new DB VM with 512GB of ram to start with. We’ll see how it goes from there

They don’t generally like it when I start a convo haha

We do have several virtual db’s in production though and always looking to migrate away from bare metal where it makes sense (one of the new vm’s is a remote AlwaysOn read-replica)

We have a few test servers running windows/sql 2022 - all running fine at the moment, but I do recall hearing some issues with a windows patch causing reboot loops

The game cluster runs an intra-cluster heartbeat for all the nodes and then there are other tools that monitor the machines themselves, the operating system, and the SQL Server.

I’m not sure I understand the question; but all the machines run Windows Server as their operating system.

Difficult to say without knowing more details. I just tested logging in and opening a non-Jita market and it opened in a subsecond and everything was very responsive as I clicked around. This could be client-side because it needs to process your orders to highlight them but could be something else. Does the client halt, does it spin up to 100% CPU, does it log while this is happening?

There are specific nodes that handle the mapping requests that are sent via https://community.eveonline.com/support/fleet-fight/ but those are (currently) running on the same type of hardware as the TQ Tech IV “rank-and-file” machines as those machines perform better than the dedicated hardware in TQ Tech III.

The benefit of sending in Fleet Fight Notifications is that the solarsystem will be isolated on their own node (like Jita is all the time) instead of being mixed with about 20-40 other solarsystems. Then in 1-3 years when we start upgrading again, then the fleet fight nodes will be moved to the best hardware each time.