fivem-redm-performance-network

FiveM / RedM のパフォーマンスとネットワークの最適化

resmon CPU と ネットワークバイト数に特化したスキルです。一般的な実装やネイティブ関数の百科事典ではありません。

必要な場合にのみリファレンスを読み込んでください。3 つすべてを事前に読み込まないでください。

ファイル	開くタイミング
references/profiling.md	計測、ハッチの種類、resmon、プロファイラー、neteventlog、検証
references/fivem-networking.md	イベント、latent、初回 GET キャッシュ、msgpack/JSON、ルーティング/-1、ステートバッグ、コールバック、帯域幅の計算
references/lua-hotpaths.md	スレッド、Wait、ネイティブ関数、プール、割り当て、NUI、GetPlayers、起動時の SQL 読み込みキャッシュ

ネイティブ関数のシグネチャが不明な場合は、ネイティブ関数のリファレンスで確認し、推測しないでください。ネットワーク ID を検証し、クライアントを決して信用しないでください。このスキルでは、一般的なスキャフォールディングや OneSync のエクスプロイト百科事典は扱いません。

---

目標

適切な同期とゲームプレイを変えないことを維持しながら、CPU とネットワークトラフィック とイベントの乱発 とペイロードサイズを削減します。

0.00ms でもイベントを大量に送信しているリソースは、最適化されていません。ネットワークログが静かでも、Wait(0) でプールをスキャンしているなら最適化されていません。

盲目的に最適化しないでください。計測値を捏造しないでください。バイト数を節約するためにサーバーの検証を弱めないでください。

---

ワークフロー

1. ゲーム（FiveM / RedM / 共通）と処理側（クライアント / サーバー / NUI）を特定します。
2. 計測するか、推定値として明記します。references/profiling.md を開きます。
3. 以下のチェックリストで grep します。見つかった箇所を CPU、ネットワーク、または両方に分類し、Critical / High / Medium / Low の優先度を付けます。
4. 修正を提案する前に、該当するリファレンスを開きます。
5. ゲームプレイ、同期、ルーティングバケット、権限、exports、NUI、フレームワークの状態を維持します。
6. 変更前と変更後を、実測値と推定値を区別して報告します。

---

デフォルト設定（常に適用）

• 安全な範囲で最も長いスリープを使います。Wait(0) は真にフレームごとの処理に限ります。
• 状態を監視できる場合は、ポーリングよりイベント駆動を優先します。
• 有効な範囲で最小の宛先を指定します。すべてのクライアントが受信する必要がある場合に限り -1 を使います。
• 完全なペイロードは（参加時 / 初回 GET / リソース起動時に）一度だけ送信し、その後はクライアントまたはサーバーでキャッシュします。以降のトラフィックは差分のみとします。
• DB の行はリソース起動時またはプレイヤー参加時にサーバーのメモリキャッシュへ読み込みます。データが実際に変更された場合にのみ、データベースにクエリまたは書き込みを行います。
• 最初のスナップショットの後は、プレイヤーやインベントリ全体ではなく差分を送信します。
• ネットイベントは msgpack を使います。余分な json.encode は CPU を消費します（送信する場合は大きな文字列にもなります）。
• latent イベントは、大きく、レイテンシーが重要でないペイロードに限って使います。
• このティック内ではネイティブ関数をキャッシュします。常に最新である必要がある値はキャッシュしません。
• パフォーマンスの変更後も、サーバーは source、権限、数量、所有権、距離、バケット、クールダウンを検証します。
• yield の前に local src = source を設定します。

---

Grep チェックリスト

リソース全体の両側を検索します。

• CreateThread / Citizen.CreateThread / while true
• Wait(0) / Wait(1) / Wait(5) / Wait(10)
• TriggerServerEvent / TriggerClientEvent / TriggerLatent
• -1 を指定した TriggerClientEvent
• RegisterNetEvent / AddEventHandler / TriggerEvent
• GetGamePool / GetActivePlayers / GetPlayers
• json.encode / json.decode
• SendNUIMessage
• MySQL / oxmysql / .query / .query.await
• GlobalState / .state / AddStateBagChangeHandler
• lib.callback / emitNet

各イベントについて、ローカルか C→S か S→C か、頻度、ペイロードの形式、受信対象、ループ内かどうかを確認します。

---

優先度

Critical — フレームごとの Trigger*Event、毎フレームの GetGamePool、毎ティックの大きな JSON、サイズの大きいデータの -1 ブロードキャスト。

High — 頻繁なループ、不要なブロードキャスト、大きなペイロード、コストの高いネイティブ関数、ループ内の同期 SQL。

Medium — 繰り返し発生する割り当て、冗長な計算、非効率なテーブルスキャン。

Low — resmon では確認できないマイクロ最適化。

Critical が残っている間は、Low に時間をかけないでください。

---

編集する前に

1. アーキテクチャ、イベントの利用箇所、クライアントとサーバーの境界を理解してください。
2. イベントを削除する前に、リソース全体とその依存先をすべて検索してください。別のファイルやリソースで使われている可能性があります。
3. エクスポート、コールバック、NUI、フレームワーク連携、ステートバッグを確認してください。
4. ユーザーから依頼がない限り、インベントリ、お金、権限、エンティティの所有権、ルーティングバケットの動作を変更しないでください。

最適化のために動作を変更する必要がある場合は、そのことを明確に伝えてください。

---

レポート形式

概要

主なボトルネックを短い段落で説明してください。

パフォーマンス

Before:   (measured | estimate)
After:    (measured | estimate)
Expected: ...

ネットワーク

Event:
Frequency:
Payload:
Recipients:
Estimated bandwidth:

変更点

重要な変更点と、その理由をそれぞれ示してください。

リスク

同期、ゲームプレイ、または検証に関するリスク。

残っているボトルネック

次に測定すべき項目。

検証

resmon／profiler／neteventlog（references/profiling.md）を使って確認する方法。