Live data from Hacker News

Testing a 1,000 player Minecraft server with Folia

cubxity.dev

161–166 of 166 posts

Re: Testing a 1,000 player Minecraft server with Folia

#161
post #3

Very excited to see how far minecraft servers can be pushed! If anyone is curious why you’d want to have 1000 players in minecraft, this video documents a pretty amazing example scenario: https://youtu.be/zv-TS_mEHE4

I wonder if we’re going to look back on how YouTubers talk in the same way we look back at stereotypical forced accents on corporate news channels. It feels so unnatural

Re: Testing a 1,000 player Minecraft server with Folia

#162
post #77

Earlier quoted context omitted.

Pooling would have been more overhead than allocation + deallocation? Do you have any relevant readings? No idea how to do it in java but a few pointers ought to be enough. You can also omit clearing the memory area between allocations for things that aren't security sensitive, if that is done in java, which I would assume.

Allocation + deallocation might have more overhead together. I'll try to rephrase: Requesting an object from a pool might have more overhead than allocating a fresh object, and deallocating the object doesn't happen on an application thread but on a GC thread (depending on the GC, obviously). Alexksey Shipilev has good resources how GCs in HotSpot typically allocate objects ( https://shipilev.net/jvm/anatomy-quarks/4…

Seems like there should be a performance benefit from not constantly blowing out your L2 cache. If you can keep your object pool hot there should be quite a bit of performance to be gained. The downside is that this would require active memory management (explicitly freeing the objects when you're done with them) and if you have that why bother programming in a GC language in the first place?

Re: Testing a 1,000 player Minecraft server with Folia

#163
post #51

While very impressive, something to note: >The server was prepared with a 100k x 100k block pre-generated world. Our custom plugin distributed new players to the least-occupied region. Minecraft chunk generation is notoriously though, and even a few players generating new chunks will bring the TPS down to an unplayable state very fast.

"generating new chunks" That's not happeneing, it says "pre-generated world"

That's the point. The test doesn't include chunk generation.

Re: Testing a 1,000 player Minecraft server with Folia

#164

Earlier quoted context omitted.

"generating new chunks" That's not happeneing, it says "pre-generated world"

That's the point. The test doesn't include chunk generation.

Oops, I didn’t read that properly I guess

Re: Testing a 1,000 player Minecraft server with Folia

#165
post #39

Earlier quoted context omitted.

Ha, nice, thanks. I've never looked into this deeper than accepting the fact that it's doable. Now, if only I had the spare time to look into how did they shard the servers...

ocelotpotpie's sibling reply to this has good explanations for the terminology. If you're curious to actually see the software: * https://www.spigotmc.org/wiki/bungeecord/ - Older, less-performant but still used by some teams * https://papermc.io/software/velocity - Newer, more performant, maintained by the team that makes Paper, one of the leading performance MC server implementations. For context of scale btw, when…

That is 100 players per server = 12.5 players per hardware thread. The linked article got 31 players per available hardware thread, but was only able to saturate part of the CPU landing at about 70 players per used hardware thread. The TPS also dropped by a factor of 3. If you were running at 50% utilisation and maintained 20 TPS, then I don't see a significant increase in performance. I imagine I'm missing the point ;)

Re: Testing a 1,000 player Minecraft server with Folia

#166
post #143

Earlier quoted context omitted.

But each has to do a lot of stuff. People on such big servers build farms with hundreds of mobs dropping thousands of items which then go through redstone sorting systems.

Thousands of items is small. Factorio doesn't need that amount of RAM when it routinely handle dozen of thousands of items every ticks.

> Factorio doesn't need that amount of RAM when it routinely handle dozen of thousands of items every tick.

It might not inefficiently allocate all that RAM every tick, but it still has to scan a lot of RAM, and write to a bunch of locations to update the game state.

It loves CPUs with huge caches because of that.

Post reply on HN