Nico
0173a434f4
Manage Arthoran as a persistent level-60 tank profile, add Worgen forms and mounts, enable PvP and recruit through native LFG with preparation actions and player invitations. Reduce repeated route and flight-planning work, bound failed-travel retries and add runtime timing diagnostics. Include 86 passing tests and measurements with 110 online bots.
4.7 KiB
Clientless performance, 2026-10-29
The test installation has twelve logical CPUs. The initial process sample showed
95.1% of one CPU in the world thread and about9.9% in the single map worker.
The existing build is Debug (-g, no optimization); these are not production
Release/RelWithDebInfo capacity numbers. Production infrastructure was untouched.
Observed bottleneck
External perf/ptrace sampling was denied by OS permissions. No kernel settings were changed. CPC_PERF now reports steady-clock time in travel, perception, transport, flight, actions and controllers every30 seconds. Times include blocking and are not CPU percentages. The controller bucket includes login preparation. CPC_ROUTE reports searches taking at least50ms, separating future MMAP probes, current-player entry probes and dynamic flight-cost evaluations.
An initial31.923-second window with16 managed characters spent24.381 seconds inside actions. Perception used27ms; controllers1.032 seconds. A later20-character window spent27.872 seconds in actions over31.537 seconds. A traced warm search made21,456 flight-cost calls and spent292.767ms there out of355.109ms total. Static future MMAP probes used only0.365ms and current entry probes0.637ms.
Changes
- Flight planning snapshots profile eligibility, minimum-distance configuration and preferred zones once per synchronous planning scope. Scope exit clears it. Actual departure checks still use live eligibility. Map licenses, area mount rules and dynamic restrictions remain evaluated. Area keys now use exact binary coordinates instead of repeatedly formatting and parsing floating-point text.
- Successful static ground probes between graph points are reused across plans. Cache keys include map, instance, direction and exact endpoints. Storage is bounded to32,768 proofs. No Player paths, negative/transient results, Detour objects or tile pointers are retained. Graph reload clears the cache. Reload the graph after replacing MMAP data. Execution still validates actual movement.
- Fixed graph neighborhoods are reused, bounded to4,096 entries. A cube shortlist preserves the original exact distance, route-blocklist and path checks.
- Current-player entry probes are shared only within the same immutable planning request, including its two search tiers. They never become global route proofs.
- Consecutive failed destinations back off from2–3 seconds to a maximum30 seconds, with per-bot jitter. New intents reset this state. Deadlines are unchanged; combat and immediate social/damage notifications are not delayed.
- The active test config uses MapUpdate.Threads=4, previously1. Network and database worker settings were retained. Native map jobs can run concurrently; bot/Lua/ Player-manager work remains on its owning world thread. A single map update is still serial. Arbitrarily parallelizing those managers would introduce races.
Verification
All86 clientless tests pass. Tests cover scoped configuration reuse without extra reads over1,000 estimates, fresh departure eligibility after the scope, exact area coordinates and phase-aware terrain queries, unchanged routes, route-specific blocklists, cold/warm proof reuse, map/instance isolation, bounded caches, two-way map-thread notice handoff, bounded retry timing and immediate new-intent reset.
Native warm searches with about20,000 flight-cost calls fell to roughly34–37ms in flight evaluation and around100ms total. Targets and actor positions differ between live windows: this is an observed workload comparison, not a deterministic before/after benchmark. Early cold queries can still take longer. With retry backoff, a30.006-second window at84 managed characters spent7.114 seconds in actions and1.848 seconds in controllers. With all110 bots online (50/5/50/5, no pending logins or loader error), the next 30.011-second window spent7.762 seconds in actions and1.612 seconds in controllers. A10.069-second /proc sample recorded26.2% of one CPU in the main thread and 38.6%,37.6%,38.1%,38.5% in the four map workers. The process remained ready and TCP8085 listening. Samples cover different live workloads; they do not establish a fixed speedup or guaranteed capacity. Evidence is in checkpoints/2026-10-29-performance.
Remaining limits
Compiler optimization is still required for a meaningful production capacity test. No existing Debug CMake configuration was replaced. Native map updates, initial character preparation and cold terrain loads can still produce individual spikes. Four map workers do not parallelize one continent, and the bot controllers are still world-thread owned. No claim is made that1,000 bots or production load has been accepted. User in-game acceptance remains separate from automated tests.