仲間ノート作成活動「第五回青少年合宿」参加10日目です。
序文
この記事では、主に実際の業務サービスのパフォーマンス最適化の事例と、比較的複雑なロジックを持つプログラムのパフォーマンス最適化を行う方法を紹介します。
最適化の種類は、ビジネス サービスの最適化、基本的なライブラリの最適化、および Go 言語の最適化に分けることができます。
ビジネス サービスの最適化
基本的な考え方
- サービス: 独立して展開でき、特定の機能を実行できるプログラム
- 依存性: ServiceA の関数実装は、ServiceA と呼ばれる ServiceB の応答結果に依存します ServiceB に依存します
- 呼び出しリンク: インターフェース要求とそれらの相互依存関係をサポートできる一連の関連サービス
- 基本ライブラリ: 公開ツールキット、ミドルウェア
上の図は、システム デプロイメントの簡単な図です。クライアント リクエストは、ゲートウェイによって転送され、さまざまなビジネス サービスによって処理されます。ビジネス サービスは、他のサービスに依存する場合があり、ストレージやメッセージ キューなどのコンポーネントに依存する場合もあります。
次に、ビジネス サービスの最適化を例として、パフォーマンス チューニングのプロセスを説明します. 図の ServiceB は、ServiceA に依存し、ストレージと ServiceD にも依存しています。
プロセスを最適化する
- サービス性能評価手段の確立
- パフォーマンス データを分析し、パフォーマンスのボトルネックを特定する
- 主な最適化項目のレトロフィット
- 最適化効果検証
サービス性能評価手段の確立
- サービス性能評価方法
- 単一のベンチマークでは、複雑なロジック分析を満足させることはできません
- 異なる負荷条件下でのパフォーマンスの違い
- リクエストのトラフィック構造
- 異なるリクエスト パラメータのオーバーライド ロジックが異なる
- 実際のオンライン トラフィック
- 圧力範囲
- スタンドアロン圧力試験
- クラスター圧力試験
- 性能データ取得
- スタンドアロンのパフォーマンス データ
- クラスタ パフォーマンス データ
ロジックが複雑なため、リクエストパラメータが異なれば処理ロジックも異なり、対応するパフォーマンスも異なります.実際のパフォーマンスのボトルネックを分析するには、可能な限りオンラインで実際の状況をシミュレートする必要があります.
プレッシャー テストでは、オンライン リクエスト トラフィックを記録し、再生速度を制御してサービスをテストします. テスト スコープは、単一のインスタンスまたはクラスター全体にすることができます. 同様に、パフォーマンス コレクションも、単一のマシンとクラスターを区別します.
評価方法が確立された後、サービスパフォーマンス指標分析レポートが生成されます。
実際のストレス テスト レポートでは、ストレス テスト中のサービスのさまざまな監視指標 (qps、遅延など) がカウントされます。同時に、ストレス テスト プロセス中に、サービスの pprof データも収集され、パフォーマンスの問題が発生する可能性があります。前の方法で分析できます。
パフォーマンス データの分析
パフォーマンス データを分析し、パフォーマンスのボトルネックを特定する
サービス最適化前のパフォーマンス レポートといくつかのパフォーマンス サンプリング データを使用して、パフォーマンスのボトルネック分析を実行できます。
业务服务常见的性能问题可能是使用基础组件不规范。
比如下面代码，每次使用配置时都会进行json解析，拿到配置项，实际组件内部提供了缓存机制，只有数据变更的时候才需要重新解析json。
还有可能是：高并发场景优化不足
上边是服务高峰期的火焰图，下边是低峰期的火焰图，可以发现metrics，即监控组件的CPU资源占用变化较大，主要原因是监控数据上报是同步请求，在请求量上涨，监控打点数据量增加时，达到性能瓶颈，造成阻塞，影响业务逻辑的处理，后续是改成异步上报的机制提升了性能。
重点优化项改造
定位到性能瓶颈后，修改完后能直接发布上线吗？
- 正确性是基础
- 响应数据diff
- 线上请求数据录制回放
- 新旧逻辑接口数据diff
性能优化的前提是保证正确性，在变动较大的性能优化上线之前，还需要进行正确性验证，因为线上的场景和流程太多，所以要借助自动化手段来保证优化后程序的正确性。
线上请求的录制，要包含请求参数录制、返回内容录制，重放时对比优化前后返回内容进行正确性验证。
优化效果验证
- 重复压测验证
- 上线评估优化效果
- 关注服务监控
- 逐步放量
- 收集性能数据
改造完成后，可以进行优化效果验证了。
验证分两部分，首先依然是用同样的数据对优化后的服务进行压测。
正式上线的时候会逐步放量，记录真正的优化效果。
压测并不能保证和线上表现完全一致，有时还要通过线上的表现再进行分析改进，是个长期的过程。
进一步优化
进一步优化，服务整体链路分析
- 规范上游服务调用接口，明确场景需求
- 分析链路，通过业务流程优化提升服务性能
基础库优化
基础库优化使用范围更广，在实际的业务服务中，为了评估某些功能上线后的效果，经常需要进行AB实验，看看不同策略对核心指标的影响，所以公司内部多数服务都会使用AB实验的SDK，如果能优化AB组件库的性能，所有用到的服务都会有性能提升。
ビジネス サービスの最適化プロセスと同様に、まず各サービスの AB コンポーネントのリソース使用量をカウントし、AB コンポーネントのどのロジックがより多くのリソースを消費しているかを確認し、重要な最適化のために共通の問題を抽出します。
SDK の最適化には主に次のものが含まれます。
- 基本ライブラリのコア ロジックとパフォーマンスのボトルネックを分析する
- 改修計画の設計と改善
- オンデマンドのデータ
- データシリアライゼーションプロトコルの最適化
- 内圧試験検証
- プロモーション事業サービス上陸確認
Go 言語の最適化
Go 自体の最適化は、コンパイラとランタイムのメモリ割り当て戦略を最適化し、より効率的な go リリース バージョンを構築します。
Go 言語の最適化は、主に次のようなコンパイラとランタイムの最適化です。
- メモリ割り当て戦略を最適化する
- コードのコンパイル プロセスを最適化して、より効率的なプログラムを生成する
- 内圧試験検証
- プロモーション事業サービス上陸確認
この最適化ソリューションは簡単にアクセスでき、エディターのコンパイル構成を調整するだけでよく、強力な汎用性を備えています。
要約する
- パフォーマンス チューニングの原則
- 当て推量ではなくデータに頼る
- パフォーマンス分析ツール
- pprof ツールを使用してパフォーマンスの問題をトラブルシューティングし、その基本原則を理解することに精通している
- 性能調整
- 正確性の保証
- 主要なボトルネックの特定