Player Features and Ideas Discussion

Maybe in accounting.

Yeah possible that the VMWare license is pretty expensive, to be honst I don't actually know that cause I just use it.



Totally agree with this. Just was curious about the technical side.

While virtualization is very nice, it also do add one extra layer on performance, especially if there is custom built servers for specific purposes. I'm sure CCP is evaluating the use of virtualizing things they can and the impact it may have.

As for the license costs, that wouldn't be too bad in the big picture.

/c

There is always KVM that can do the same without license costs if that is the problem.

My guess is: One does not simply change the underlying infrastructure of a running gamecluster.

But i'm sure they are exploring that option and they will introduce it as soon as they think it won't obliterate our shiny internet spaceship world.

It would be very interesting to read maybe a devblog about this stuff and what the challenges are in this case.

Based on what I know of the EVE codebase, I highly doubt virtualization would help. Virtualization favors distributed and randomized loads. When 500 ships land on one grid, they likely need all the horsepower they can muster for a small number of threads.

Virtualization is done on servers to reduce maintenance costs, not improve performance of individual nodes.

Virtualization is done on desktops to group underutilized systems, and to reduce maintenance costs, not to improve performance of individual nodes.

Sure, VMWare and Citrix will tell you it will increase performance, but I have yet to see a business case that proved it in reality. In most cases, it saved money but end users are not happier.

He was suggesting that it would help them with dynamic resource allocation when a node is overloaded by being able to beef it up on the fly. By adjusting the amount of CPU shares/memory shares that the shard that is geting hammered gets.

Yeah a lot of the current issues are due to the limitations currently in place on dynamically reinforcing a node when things kick off unexpectedly.

A lot better solution in the long run would be (and probably something CCP has ongoing) profiling these fights to see what the big performance hits are and where those can be adjusted. Its quite common for instance to have things in the initial implementation of a design that are processed synchronously in realtime that down the road you can adjust so they are less time sensitive and processing on them can be deferred, etc.

going to a vm architecture could theoretically be of some benefit given my understanding of how the eve cluster works. it would allow live migration of systems off a "hot" node without interrupting user connections. Eve can already do this, but it boots users off in the process forcing them to reconnect. it would also allow lots of idle systems/nodes to be collapsed onto less hardware, and moved around as needed.

since the guts of eve are single threaded however, this would probably not help the "3,000 users logged onto one system/grid". if anything even the small vm overhead hit would make that case worse. ironically the case you want to optimize most.

you'd have to weigh the benefits of being able to seamlessly move everyone else off a server vs the overhead of running in a vm. You CAN run high performance stuff in vmware by dedicating cpu/ram to your vms (its a setting that grants the virtual machine it's own cpu not shared with anyone else). I run some heavy duty exchange and SQL servers like this with great success (the benefits far outweigh the performance hit for my applications).

however i'm guessing that ccp has really smart folks that looked at this already and decided it's not worthwhile for this setup. "Just boot users off when you migrate/reimburse for disconnect losses" works for free. Their time might be better spent figuring out how to live migrate a stackless python process directly, if they cant multithread a system.

it's a tough problem. kind of like trying to upgrade your single engine stunt plane into a quad engine jet aircraft. While flying. With 57,000 screaming passengers onboard.

VMWare isn't the be-all and end-all of virtualization (there are perfectly reasonable free virtualization options, so licensing isn't the problem).

What would make more sense for this application isn't server virtualization, but moving towards an actor model so that people can interact directly in space without needing to be on the same CPU. Blizzard is on the list of Akka users, so I suspect they are already moving in that direction, and I would be shocked if CCP isn't also looking at how to get the same effect on their Python-based server platform.