Fixing Lag: Picking Up Low Hanging Fruit | EVE Online

Fixing Lag: Picking Up Low Hanging Fruit

2010-09-13 - 作者 CCP Veritas

Greetings folks,

Just wanted to toss you folks a quick nugget of what we in the lag-fighting force have been up to lately.  This report is for one inefficiency that was found while doing thin-client testing; the result of which has been live on Tranquility for a while now.

Hope you enjoy,

~CCP Veritas


Player Module Repeat Optimization (8.5 Awesomes)

The Problem:

Thin client tests showed that modest numbers of clients shooting civilian lasers caused unreasonable CPU usage.  Since civilian lasers don't use ammo, this removed inventory as a cause of load, and left what should be a very simple damage calculation.  Analysis showed that most of this CPU time was spent determining if the module was in the process of reloading whenever it was repeated.

The Hypothesis:

The query to tell if a module is repeating required setting up a full ship object then querying it.  The data needed to fulfill that query, however, is contained in a separate ship cache object which means having a full ship object is not required to perform this query.  Removing the instantiation of that object and going directly to the cache instead should give significant improvement.

The Test:

Setup:  50 Maelstroms with 8 Civilian Gatling Pulse Lasers, 6 Civilian Shield Booster I's, and 5 Civilian Armor Repairer's at close range, firing all guns and repeating all modules, for a total of 950 effects being managed.  The flag to turn on the optimization was turned on without change to the clients' activities.

A drop from approx 82% CPU to approx 35%, a 57% improvement

This optimization should have very wide impact, as players using modules is a very common thing.  Estimated performance gain on a real-world Sol (servers that run game logic) is somewhere in the 5% ballpark, as player module repeating takes around 8-12% of current CPU slices.

TQ Impact:

On August 24th, I tested the waters turning this optimization on a Sol that was very busy managing missioners.  The result was encouraging:

The optimization was turned on cluster-wide during downtime on August 30th, and the trend appears to follow expectation, around a 5% drop in general CPU usage:

Conclusion and Future Work:

For such an easy fix, this had a substantial impact, thus earning the highest Awesomeness rating to date.  Work should continue in finding the performance bottlenecks of this extremely basic test case, as it represents the foundation of the fight mechanics in EVE.