I'm experiencing a performance issue that appears to stem from AE2 on my server.

Description

The console output includes dropped ticks from time to time, such as
[21:23:27] [Server thread/WARN] [minecraft/MinecraftServer]: Can't keep up! Did the system time change, or is the server overloaded? Running 2465ms behind, skipping 49 tick(s)

Running LagGoggles (mod) to try to diagnose the issue, it points to the AE2 event handler thread, as seen here: https://cdn.discordapp.com/attachments/400256669713563651/596166312083062787/unknown.png

When running /forge tps or /cofh tps, no tickrate lag is reported. Tick time is in the 30-40ms range.

VisualVM Profiler snapshot: https://jimmy-public-files.s3-us-west-2.amazonaws.com/AE2DebuggingProfilerSnapshot.nps

Environment

Server is Windows 10 Educational x64, client is running on the same system.
Java version is:
java version "1.8.0_212"
Java(TM) SE Runtime Environment (build 1.8.0_212-b10)
Java HotSpot(TM) 64-Bit Server VM (build 25.212-b10, mixed mode)
Same behavior see on an older java version (1.8.0_181)

• Minecraft Version: 1.12.2
• AE2 Version: appliedenergistics2-rv6-stable-6
• Forge Version: forge-1.12.2-14.23.5.2838-universal

Modpack is Omnifactory version 1.2.1, with the only change being Channels being enabled.
World can be provided if needed.
Thanks!

I'll throw in the usual questions here, nothing fancy but known things that can help

a) did you make sure to keep the whole network chunkloaded (parts unloading bec ause being too far away, including QNBs in other dimensions, will cause reboots due to the network loosing and gaining parts whenever they are reloaded)

b) always make sure to have enough AE2 Energycells connected, because ME systems can only accept as much RF/tick as they have internal capacity, regardless on how much energy you throw at the acceptor!

c) try to keep attached inventorys (like barrels on storage busses) as simple as possible, like storage drawers "compacting drawer" will cause funny things to happen and recipe calculation can turn into a major calculation effort and overly big inventorys also will introduce strain on autocrafting calculation

sidenote to a) wierdingGadgets chunkloaders work very well, chickenchunks chunkloader will load the area just fine as long as they properly loaded once but to make em load properly on world reboots(which they seem to struggle, also with some optimizing mods), throw an additional spotloader on top of it or use spotloader only in the first the place as they work flawless, but those are the only two that i have tested throughly without issues

A) The entire network is local to one dimension (no QNBs), and is entirely chunkloaded, both because I'm standing there and because it's loaded via FTBU

B) There is a dense energy cell on the network. It remains basically full at all times.

C) There are many storage buses (and fluid storage buses), although none are on extensive inventories. The largest drawer network I have is ~10 drawers, although there are some compacting drawers.

although there are some compacting drawers.

try to exclude them for a brief moment from your system to check if it actually helps ... heck i did even forget to ask:

D) did you try to stop any autocrafting and reenable it bit by bit until you notice lag increase? If the lags stem from a particular recipe, it's ingredients may be stored in an unfavorable fashion

i don't have much faith in the FTBU Chunkloader Tickets, i think they are linked to the player being online and on a server this can still create havoc (not in single player which i assume here to be the case but just as a sidenote)

storage drawers was more like an extreme example, deep storage units and other super large inventorys can cause issues too (somthing in the way forge deals with inventorys makes it neccesary to do workarounds which cause performance issues)

I tried removing storage buses, first just ones with compacting drawers, then all storage buses, and it didn't help appreciably. It felt like it may have been worse, although my measurement methods weren't particularly precise.

It'll be extremely difficult to get rid of all autocrafting. I have a large number of export buses/interfaces with crafting cards scattered all around. I disconnected all of my crafting CPUs from the network, so that no autocrafting would actually run, and that definitely made the problem worse, presumably because all export buses/interfaces were re-calculating their crafting plans more often.

There are a few issues here.

1. It repaths the network to some degree. So either it is not chunkloaded or somehow it's constantly changed. But this has only a minor impact.
2. For each crafting step is a crafting event send. Here Crafttweaker listens for them and it actually has a noticable performance impact. I'd guess it is simply not designed in mind with crafting speed AE2 can achieve, more like the very limited options of a vanilla crafting table. Nothing we can really fix on your side
3. The major offender is simply the decision to add item capabilities by Forge. Especially when using any external inventory it has a massively increased effect. That is completely up to Forge to fix, but I do not really expect it.

No idea about the changes when disabling external storage/etc without any data. With LagGoggles being utterly worthless in general. I'd simply guess with the major offender being removed, rebuilding the network or CT simply has more time available before being skipped.

oh and to add, there is a slight chance that even with everything being "by the looks" chunkloaded does not mean it is chunkloaded as FTBU is respecting the config for maximum number of loaded chunks and might still unload them, but i have no idea how to check it (i think there is a config in the forge config file)...

is the chickenchunk feature where you type /chunkloaders and get a window with all loaded areas and chunkloader-tickets still a thing!?! you may have simply overseen a chunk or try he recommended ones to see if it performs better then

I'll add chickenchunks and have it also load my base, won't hurt to be sure.

Does the "item capabilities" issue mean that I can get improved performance by only using native AE2 storage cells as inventory? If so, I'm willing to drop as many of the storage buses as possible, and stick to using level emitters to disable machines.

During testing, I seemed to notice a correlation between the amount of lag, and the # of automated crafting requests that could not get fulfilled. Is it possible that failing to generate a crafting plan is more expensive than successfully calculating one (perhaps because more of the recipe tree has to be searched), and because an export bus that fails to craft it's item will re-try soon?

Idea for AE devs for Crafting with crafting cards.

Instead of recalculating the entire craft, remember one of the required items that were missing. Then before requesting the craft next time check if the required amount is in the system. Should probably reset if the contents of the interface change and such but that should be pretty straightforward.