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.
75 lines
4.7 KiB
Markdown
75 lines
4.7 KiB
Markdown
# 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.
|