Chocolate Quest Repoured

Chocolate Quest Repoured

2M Downloads

TPS issues with large dungeons on servers

shanzenos opened this issue · 9 comments

commented

Common sense Info

  • I play...
    • With a large modpack
    • Only with CQR and it's dependencies
  • The issue occurs in...
    • Singleplayer
    • Multiplayer
  • I have searched for this or a similar issue before reporting and it was either (1) not previously reported, or (2) previously fixed and I'm having the same problem.
  • I am using the latest version of the mod (all versions can be found on github under releases)
  • I read through the FAQ and i could not find something helpful (FAQ)
  • I reproduced the bug without any other mod's except forge, cqr and it's dependencies
  • The game crashes because of this bug

Versions
Chocolate Quest Repoured ('latest' IS NOT a valid version! Please use the version string that shows up in the mod overview of forge): CQR 2.2.4B
Forge: 14.23.5.2854
Minecraft: 1.12.2

Describe the bug
Large dungeons with many CQR enemies absolutely destroy TPS. My server is as optimized as I can get it (mohist) via settings for bukkit, sponge, etc. and it is being hosted in a linux container with plenty of ram and vcpu's dedicated to it. TPS drops are not as hard with smaller dungeons and fairly ignore-able, but dungeons like the massive specter castle will often drop to 2-3 TPS with just 3 players.

To Reproduce
Steps to reproduce the behavior:

  1. Activate the spanners and aggro enemies in any of the massive scale dungeons.

Expected behavior
Can't really say, you guys have been trying to optimize TPS issues with the mod for awhile, and certainly come a long way with it to the point only a few dungeons really affect it.

Screenshots
https://i.imgur.com/RFpINbH.jpg

commented

Can't reproduce this on a Raspberry Pi 4 and 4 players. (I typed "3" but meant a Pi 4, the 3 can't even run a forge server properly. I tend to confuse those)

What you can do to avoid TPS problems cause of generation completely is to pre-generate your worlds.
I also recommend you to not run the server in a container. Containers are tools meant for deployment. And running a MC server in a container is a bad idea cause these things technically are VM's. Also VCPUs aren't near as good as real CPUs, that makes a huge difference.

commented

Thanks for the quick follow up. I'm aware my setup is not ideal, I simply wanted to stress it's not running off a potato home PC with a VPN or something. I'd figure CQR + a decent sized pack probably needs more horsepower.

commented

Yes. What you can still try are the following methods:

  • Install BetterFPS & Phosphor if not installed already
  • Lower the "spawnerActivationDistance" in CQR's main configuration, that affects the range at which spawners begin to spawn mobs

If these 2 (especially the second) method has zero effect on new structures (it won't work for old ones as the entities already spawned) then please verify that the issue is CQR by removing every other mod in the pack except performance optimization ones and the CQR dependencies and provide us a Java Profiler Report.

Honestly i can recommend you an old potato pc over using a VM. I used to run a server (private one, few players) on an old PC in my basement. The PC had an antique Intel Duo and 8 GB of RAM, but that was enough to run decent sized modpacks without problems. Later i got a VPS (which is a VM), which on paper had the better VCPU and more RAM but things like gameservers (e.g. gMod or Modpack Servers) ran far worse.
So i can recommend you to either look for an unused or old computer and host it at your place, if you have a good internet connection (upload rate is important, shouldn't be too low) or you could consider renting a dedicated server or root server, but one needs to search for a while to find something as cheap as a VPS (did that switch recently, my old VPS was about ~9,-€ monthly, the root server is about ~28,-€ monthly, but has far more computing power)

commented

I actually had a bit of a retard moment there, I totally forgot that I had the server moved off the virtual CPU's and onto 2 brand new xeons. And yes I run most of the major performance mods due to the nature of modded MC's poor optimization, those being phosphor, foamfix, surge, randompatches, betterfps, (optifine, on client, if player desires to run it) and borninabarn. I do however run things off a hybrid server (mohist) which tends to complicate things at times. Ontop of that the xeons I'm running off are more geared for multi-threaded performance than single. Anyway I realized that surge had been disabled server-side and without it I generally have more TPS woes, it's likely CQR is more a (albeit large) contributor toward the tps drop in it's bigger dungeons, than a direct cause. I'll check it out now that I've got surge enabled again, as well as see how one of the dungeons preforms in singleplayer so I can rule out my oddball server software and it's quirks.

commented

Yes, CQR's large dungeons (well more the large quantities of mobs inside them) can impact TPS a lot.
That is completely "normal", as CQR entities use rather complex AI's, so they are more computationally expensive than most other mobs.

Anyway: I will first believe this issue once it is reproduced under these circumstances:

  1. Server software is a forge server
  2. Any other mods besides CQR and it's dependencies are things like performance optimizers
  3. You can proof this issue by providing a Java Profiler Report of the server
  4. Lowering the spawnerActivation distance DID NOT help
  5. This of course has to happen in a brand new world. Player amount doesn't matter.
commented

OK, so i ran a quick test to see if it really is an issue:
Server software: Magma b2a81d7 with forge 2855 (only used cause of bungeecord/waterfall support which standard forge server doesn't have)
CQR: 2.2.4B
Other mods: FAWE (Worldedit), Phosphor, CQR dependencies (LLib)

TPS without any loaded mobs: 20 (mean tick time: 9ms)
TPS directly after placing the rCastle (no mobs yet): 20 (mean tick time 5ms)
TPS after spawning a lot of mobs in the castle (aka going into survival with the difficulty > 0): 20 (mean tick time: 10ms - 13ms (did that with 4 accounts at the same time)
If you want proof for these test values i can send you the screenshots of the tps values, i sadly didn't have the time to set up a proper profiler on that server.

So the issue doesn't seem to be CQR, yes the mean tick time seems to go a bit up bit it tends to be unstable when players move around and load and unload chunks.

I don't know about mohist, but i heard that magma apparently runs better, but i'm not an expert on that topic (hybrid servers), but magma runs better than the standard forge server (well, at least for me).

If you want to know the server specs used: 6GB of RAM and an Intel Core i7-4770 (4 vores @3.4GHz with a boost clockrate of 3.9GHz and Hyperthreading).

So yes: I really doubt that the issue is CQR. I also ran this test with a bigger modpack a while back on a far less powerful machine and it ran without tps trops to 5 or lower.

commented

What came to my mind: Did you maybe not update your dungeon configs when updating the mod? Cause iirc a while back the number of mobs set to spawn in rCastles (the dungeon you claim to cause the issues) was way too high, so maybe try lowering that value in it's config. If it really is just that dungeon, just disable it in it's config.

commented

I delete the CQR configs and port my settings to the newly generated config manually with a compare plugin with NP++ so no, that's not it. I did lower the distance before even posting this issue hoping it would be a temp fix but I have not had the chance to run into another large dungeon to test it with. While it is a fair sized modpack all 3 players online were present at the dungeon and I made sure to command unload the rest of the chunks to get the best performance we could. I believe I took a timings report during it, but I think it might be lost. I found another one of the same dungeon later so when I've got some time I can take a timings report and run in with surge on to see what happens. If you want for testing's sake (which, grabbing magma was already going a bit beyond than just stating you have no intent to support hybrid servers) I do still have my version of mohist I'm using I can point you toward to test.

commented

Do you mean the dungeon speparation or the spawner distance? People seem to confuse them.
Also for the record: I only use Magma cause it has bungeecord support which forge hasn't and the server runs on a small private network.