zaezae

Well the thing with that is if you wanted them to PvP all at once in one location, you'd have to allocate all of the memory to a single location (unless you're doing a cluster computer), but yes it is possible, you'd just have to switch your ports. Also it should be noted that it's not the hardware that effects how you handle the packets, it's the server US and DS. But that's also influenced indirectly by how fast the data could be processed. So theoretically, yes, if they all pvp'd on different servers. But even then, the rate would be the same because the network's US/DS is distributed across all the servers

Alright, so here's the issue; The vast majority of the server workload is networking. As you have deducted here, it is indeed packet based - the traffic we experience when players draw close to one another very rapidly easily throws our server for a loop.

I will state that this is both from personal experience and from speaking with Tythus. Tythus is the one who usually handles the finite details of server load and optimizing traffic, both due to both seemingly enjoying working on servers and the fact that due to some limitations he is the only one with enough access to the server to perform changes in it.

tl;dr is - my job is plugins/development, Tythus' "job" is running the server/optimizing it where he can. As such, I am limited in my knowledge.

So, basically the issue is that as Telanir stated - if you were to run multiple instances of Minecraft Server on separate cores you would need a logical way of communicating back and forth. Obviously, we can't quite have it so players on one server can see another - while (as NPC's have proven) it is possible to mimic a player who instead of having a connection simply has a null one such is... not an optimal thing, and adjusting variables based on player movement would do more harm than having multiple servers would do good (likely).

So, what you would need is a multiverse like setup where instead of having just a bunch of worlds on one "server" you would have one world on one server, and another on another. You would then need to figure out a way of transferring player connections (mostly) seamlessly between the next (this has already been done and is done on most popular servers, oc.tc, etc) but what Telanir said is true - we have several backend databases that have a lot of processes running at once and saves a lot of player specific data (we mainly use SQLite as per Arche's preference, and if you have some experience with it you might know it's a bit problematic) that we would have to be able to parse from both running minecraft server instances. And yes, for PvP it is generally a must. Also, one kicker too is that sadly Spigot uses a method of saving to .yml files called ConfigurationSeralizable, where items/etc. can be saved as text and loaded. We have a small issue where a majority of our items dont load properly from this method, due to our adjustments with NBT. We'd have to write a way on our own to properly save ItemStacks and load them so that cross realm transfer would be possible.

All in all, it's an idea that has merit but has some minor flaws an a huge work load for us to accomplish it. For a "PvP" world it could potentially work out.

Suppose I see the problem. Just throwing an idea against the wall. I was about to educate myself on MC fiasco but I became gainfully employed last summer so I never spent the time on it. Gosh guys, wish I knew more about it. Yeah though, very informative.

And uh, you guys have great fun with that database.