Client performance is directly related to network packet deserialization. This is exhibited with either publicVariable messages, or large AI + Player missions.

This is directly tied to the deserialization of network data prior to any actual process; the FPS is lost due to the engine receiving a large amount of messages and processing the deserialization of these messages linearly within a given render frame. This causes the per-frame render time to increase, causing FPS lag.

Excessive packet sizes cause full 100ms + stutters.

A server can directly control client FPS via specially crafting packet sizes and intervals timed to the target FPS.

This should not be the case - network packet deserialization should be offloaded to a separate thread, or throttled per render frame, to prevent excessive execution of network deserialization in any given render frame. This change occured sometime between ArmA2 and ArmA3, and has been exacerbated with the 1.38 networking changes.

Suspected Reasons:
Multiplayer network packets were given a higher priority for deserialization in the recent (~3mo) networking changes. This means that a large amount of network packets have been re-flagged as PRIORITY_IMMEDIATE, causing them to be deserialized and processed on clients on the reception frame. This has caused a drop in client FPS in multiplayer scenarios due to these packets not being properly queued and throttled for processing. Although the move to IMMEDIATE was a correct move on your part to prevent the Desync issues exhibited on release, the proper measures were not put in place for this to affect performance.

Recommendation:
It's recommended that an internal engine networking queue be established; this queue should be rate limited to a set timed execution per render cycle, with further messages being queued for processing across future render cycles. {F25585}