Practical options for EVE performance issues

Any thought of having an instanced battle is counter to what Eve Online stands for which is everyone interacting in in a single shard environment with no instancing. And besides, as the recent battle of the 9-4 Keepstar has revealed, everyone wants to dog pile. Battles are only going to get bigger and bigger which means more players want in on the action. 6,000 players in local is a huge lode on the server nodes already.

So instead of limiting the number of players engaged in battle, CCP is figuring out how to mitigate or keep under control the lagfest that occurs when you have that many players duking it out in null-sec. TiDi was the initial solution to the problem. But of course we know TiDi has its flaws and limits. But fight are better today than how it was before TiDi was first implemented.

Thus CCP is eventually going to be forced to have to rethink their server architecture that allows for bigger fights with more players in local and still have less lag than before. Instanced battles are not an option in the case of Eve Online which is mainly known for never having instanced battles.


Actually it does.

If you’re in an instance and the hard limit is reached, I can’t come along, uninvited, with some friends to mess with you; being able to do that is the very soul of Eve.

1 Like

I find it fascinating to be able to fly in and interfere with a fight at any time at my leisure.

1 Like

lol I’m far more likely to sell you the stuff to do it with than I am to do it myself.

However, fine people like yourself killing all of the things, keeps us industrial and trading types in business.

First of all, it’s not a “current design and performance crisis”. The server hardware they have allows 1000 vs. 1000 battles, where most other MMO games lag out at 40 vs. 40. It is something that CCP is very proud of, and they are constantly pushing the limits of what current server hardware can do. It’s not a crisis.


A. You’re assuming NO processor overhead from all of the stuff you’ve suggested, but the reality is that the same server processors that are busy calculating damage for 800+ players will now have to also execute all of your per-player options for inviting other parties, distributing the attendance tickets, enforcing the attendance policy, hopping in, hopping out, letting others join, etc. Your stuff is going to add MORE LAG to the whole thing, and not for the purpose of allowing more players, but to limit the players and to enforce “the options.” It’s not going to be well-received; if they currently can do a battle of 800 vs. 800 or whatever, and with your options they can only do 500 vs. 500, so that the server can have spare processor cycles for all these extra rules.

B. Sure. Neutrals crashing a party usually goes one of two ways - either they’re obliterated as they enter, because the people who are already on-grid have the grid already loaded and are already organized into ambush groups, OR, it’s a large alliance bringing a whole armada of super-carriers and titans to what would otherwise have been a small skirmish between two small entities.

C. There’s a rather large issue with “session changes” - transferring a player from one environment to another. Session changes require a large amount of processor time, for no effect other than moving the player / ship somewhere. A local encounter turning into a “deadspace” encounter would pretty much freeze everyone with a “loading screen”, and then when they finally regain control of their ships, they see… nothing different!!! It would suck.


Instances are never going to be in Eve. Plus all of your ideas either break the Eve Sandbox (literally the whole thing this game has going for it) or are incredibly easy to abuse.

Breaking systems to multiple nodes, however, same idea but different concept. Lots of different “instances” with no way to prevent players from entering any of them:

1 Like

Eve operates on the concept of a 1 second server “tick” which gets extended if the CPU needs more time to get the work done. There is no reason why the workload can’t be split up into multiple threads that use all the resources of the CPU. Current generation E7 Xeons have up to 24 cores - spread the work evenly across those cores and there would be no TIDI.

Rewriting that code would be a lot of work and the circumstances when it is needed are rare - should it be a priority?

Dont go to the big fights.

Performance fixed.


1 Like

There are already “instances” in EVE, namely the grid, where encounters can actually take place. And warp times are usually long enough that a concurrent thread could load in the data for the encounter even if it ran on a server located on another side of the real world.

I believe it could be possible to make grid encounters as actual instances that can be offloaded to a different server, given the right coding, and at the same time make them work in game just as they do now, so that technically unaware players wouldn’t even see the difference in the gameplay.

As for the encounter escalations and server transfer, yes, it may incur some extra time, but EVE is bloated by time consuming animations and mechanics, like the said warp times, so it won’t be much different from the rest of game feel anyway, imo.

As for the encounter polices, they could be in place only for the large scale encounters that require player restrictions due to hardware limits. It’s not about - you can’t join in because it’s an instance. It is about - you can’t join in because you are too late and server can’t handle your addition unless someone else drops out.

As for the flexibility that polices on instances can provide, well, that could be used in faction and alliance warfare, where there are usually pre-designated conflict points with certain parties involved. I’m not saying it has to be, just that it could be. Such option will be technically there, if anyone will want it to be put in place.

So if it is transparent, how do you know they don’t do this already.

Also they stated in multiple past threads that they actually decouple many things into seperate microservices if possible at all to spread the load. So if a grid is something that could be instanced in such a fassion they would have probably done that already.

And even if that would be possible, that does not solve the issue where you have 6000 players on the same grid like in the actual event we are talking about.

Oh wait, you talked about actual instances.

How about NO!?

My point was that you can technically make actual instances for the grid encounters and then glue them together on the solar system map and make it so that hardly anyone will notice the difference between the gameplay as it is now and then. The only difference will be in the server side infrastructure and code.

EDIT: The way EVE works now, there is only one cpu core on one server that processes a certain part of the EVE’s galaxy map, with everything that happens on it, and that kind of design, extended by legacy code and what not, is the major bottle neck for the EVE’s performance.

And my point was, if you can’t notice it, how do you know they don’t already do it this way?

I believe CCP Falcon explained how EVE works right now in the yesterday’s IN stream of 9-4 battle. See my edit above.

No it actually isn’t. As already mentioned they decoupled a lot of stuff into different microsevices already to spread the load. They don’t have only one CPU. But stuff like this is not free and easy. It adds a lot of complexity and latency as well.

There is no reason to believe the bottleneck is on the CPU. It can as well be network related, like “network cards can’t accept and buffer all the connexions that enter”, or, more likely, linked to communication errors with elements of the servers. In my case I could not dock to the keepstar, and it looks to me like the server did not store my state (“docked in keepstar”) fast enough, thus could not load back this state. I could not activate a module prior to docking, when I docked (tried to)nothing more happened (I received messages that server had not sent reponse for 40min - several times), I had log exit the game . when I logged back in, that is almost 1h30 later, I was docked in the keepstar.
I was in a scorpion and was able to jam maybe 30 fighters in the whole 6H I was on the field. +2H desync’d and logging back.

I think it’s a very more complex situation.

If you watched yesterday’s ImperiumNews stream of 9-4 battle, CCP Falcon was occasionally providing real time updates on the server status as the battle progressed. EVE has powerful servers, with a lot of CPU cores. Their load is divided into “nodes”, each covering certain regions of the galaxy map. But since the server code at the moment doesn’t support multi-threading or decentralization - i.e. cloud or distributed server infrastructure - each such “node” is physically bound to a SINGLE cpu core on the server. All CCP can do now is reinforce the “node” by designating more server resources to it, prioritizing the input, giving more RAM and so on. As it stood yesterday, the reinforced node that hosts 9-4 system was using one cpu core with constant 100% load for the most part of the battle and at some point went to allocate up to 74 GB of RAM on the server.

1 Like

Here is a relevant Reddit thread on the performance topic posted by Wulkans. I highly encourage everyone who cares about EVE’s long term health to upvote it.

Pretty easy to do real time commentary on a still life. :smirk:

–Gadget the Critic


game engine needs rewrite to future proof it as well, mass fleet battles are pinnacle of eve gameplay anything that help in those should be pursued regardless of time and cost,not only that but AI as well would massively benefit with new engine under the hood.

Bunch of dudes getting drunk in basement build eve 1.0 it is time to build 2.0 couple of games worth of time and millions of dollars are already wasted for nothing i think it is time for CCP to do something major for eve too.

First come, first “served”. Make it to the instanced battle “dead space” before other pilots can warp in, then you get to come, regardless if you were one of the parties that agreed to the battle ahead of time. If you are too late and the site is full, too bad.