サーバーパフォーマンス
サーバーパフォーマンスは、WCPOSアプリケーションの速度と応答性に直接影響します。このガイドは、組み込みのメトリックとトラブルシューティング技術を使用して、サーバーパフォーマンスを監視、診断、最適化するための手助けをします。
サーバーメトリックの理解
WCPOSは、各データ取得操作(製品、注文、顧客など)の際に自動的にサーバーパフォーマンスメトリックを収集します。これらのメトリックは、ログ画面で確認できます。
一般的なサーバーメトリック
{
"total": "24692",
"execution_time": "76.64 ms",
"server_load": "[15.20605469,16.16357422,16.76806641]"
}
内訳:
total- 処理されたレコード数(24,692の製品ID)execution_time- 操作を完了するのにかかった時間(76.64ミリ秒)server_load- 1分、5分、15分のサーバー負荷の平均
サーバー負荷の説明
サーバー負荷は、異なる期間にわたるシステムの平均負荷を表します。
- 最初の値 - 1分間の平均(15.21)
- 2番目の値 - 5分間の平均(16.16)
- 3番目の値 - 15分間の平均(16.77)
負荷の解釈
サーバー負荷の値は誤解を招く場合があり、注意して解釈する必要があります:
サーバー負荷の平均値は、パフォーマンスと直接的に相関するわけではありません。高い負荷値(15以上)のサーバーでも、十分なリソースがあり最適化されている場合は非常に応答性が良いことがあります。負荷値だけではなく、実行時間に注目してください。
一般的なガイドライン:
- CPUコアに対する負荷 - 8コアのサーバーで負荷が8.0ということは完全な活用を意味します
- 持続的な負荷vs.一時的な負荷 - 短時間のスパイクは正常ですが、 持続的な高負荷は問題を示すかもしれません
- パフォーマンスが重要 - 高負荷の応答性の高いサーバーは、低負荷の遅いサーバーよりも優れています
注意すべき点:
- 時間とともに増加する実行時間
- 説明なしに一貫して増加する負荷
- 高負荷かつ遅い実行時間の両方存在
パフォーマンスベンチマーク
実行時間のガイドライン
| 操作 | 良好 | 許容可能 | 不良 | 重大 |
|---|---|---|---|---|
| 製品取得 | < 100ms | 100-500ms | 500ms-2s | > 2s |
| 注文作成 | < 200ms | 200-800ms | 800ms-3s | > 3s |
レコード数の考慮事項
実行時間はレコード数に応じて合理的にスケールする必要があります:
// Good scaling examples
{"total": "100", "execution_time": "15.2 ms"} // 0.15ms per record
{"total": "1000", "execution_time": "89.4 ms"} // 0.09ms per record
{"total": "10000", "execution_time": "234.1 ms"} // 0.02ms per record
// Poor scaling examples
{"total": "100", "execution_time": "500.0 ms"} // 5.0ms per record
{"total": "1000", "execution_time": "8000.0 ms"} // 8.0ms per record
パフォーマンス問題の診断
ステップ1: ログを監視
- ナビゲーションドロワーからログを開く
- 遅い操作を実行する(製品の同期、注文の作成など)
- 対応するログエントリを探す
- メトリクスを見るためにコンテキストを展開する
ステップ2: メトリックを分析する
高い実行時間 + 高いサーバー負荷 = サーバーリソースの問題
{
"total": "5000",
"execution_time": "3500.0 ms",
"server_load": "[12.45, 11.23, 10.87]"
}
解決策: サーバーリソースを増やすか、サーバー設定を最適化する
高い実行時間 + 正常なサーバー負荷 = プラグイン/データベースの問題
{
"total": "1000",
"execution_time": "2800.0 ms",
"server_load": "[1.23, 1.45, 1.67]"
}
解決策: 遅いプラグインを特定するか、データベースクエリを最適化する
正常な実行時間 + 高いサーバー負荷 = 一般的なサーバーオーバーロード
{
"total": "2000",
"execution_time": "150.0 ms",
"server_load": "[8.90, 9.12, 8.45]"
}
解決策: 他のプロセスからのサーバー負荷を減らすか、リソースを増やす
一般的なパフォーマンス問題
1. 不十分なサーバーリソース
症状:
- 一貫して高いサーバー負荷(ほとんどのサーバーで> 4.0)
- すべての操作における長い実行時間
- 頻繁なタイムアウト
解決策:
- CPUをアップグレード - より多くのコアが同時リクエストをより効率的に処理します
- RAMを増やす - ディスクI/Oを減らし、キャッシュを改善します
- SSDストレージを使用 - データベースパフォーマンスを大幅に向上させます
- PHP設定を最適化 - memory_limit、max_execution_timeを増やす
2. 遅いデータベースクエリ
症状:
- 正常なサーバー負荷に対する高い実行時間
- 特に遅い製品/注文の取得
- ログ内のデータベース関連のエラーコード
解決策:
- WooCommerce HPOSを有効化 - データベースパフォーマンスの最大の改善
- オブジェクトキャッシングを使用 - ホストから利用可能な場合、RedisまたはMemcachedを使用
- WordPressを更新し続ける - コアの更新はデータベースの最適化を含むことが多い
- 投稿のリビジョンを制限する - wp-config.phpに
define('WP_POST_REVISIONS', 3);を追加
3. プラグインの干渉
症状:
- プラグインの更新後の突然のパフォーマンス低下
- 特定の操作が他と比べてはるかに遅い
- 正常なサーバー負荷に対する高い実行時間
トラブルシューティング:
- ステージングでテスト - WooCommerceとWCPOS以外のすべてのプラグインを無効にする
- ベースラインを測定 - 最小限のプラグインでの実行時間を記録
- 徐々に有効化 - プラグインを1つずつ追加して原因を特定
- プラグインフックを確認 - WooCommerceのアクションにフックされているプラグインを探す
一般的な問題があるプラグイン:
- 製品操作中の重いSEOプラグイン
- 複雑な在庫管理システム
- リアルタイム分析/追跡プラグイン
- コードの質の低いカスタムプラグイン
4. WordPress/WooCommerceの設定
症状:
- 一貫しないパフォーマンス
- ログ内のメモリ関連のエラー
- 遅い管理ダッシュボード
最適化チェックリスト:
- PHPバージョン - パフォーマンス向上のためにPHP 8.0以上を使用
- WooCommerce HPOS - 高パフォーマンス注文ストレージを有効にする(以下を参照)
- WordPressキャッシング - 利用可能であればオブジェクトキャッシングを有効にする
- WooCommerce設定 - 製品画像サイズを最適化
WooCommerce 高パフォーマンス注文ストレージ (HPOS)
HPOSはWooCommerceにおける最も重要なパフォーマンス改善の1つです。 それは注文をWordPressの投稿テーブルの代わりにカスタムデータベーステーブルに保存し、多くの注文のある店舗のパフォーマンスを劇的に向上させます。
利点:
- より早い注文クエリ - 最適化されたデータベース構造に保存された注文
- データベース負荷の減少 - 投稿やページから注文を分離
- より良いスケー라ビリティ - 大量の注文を効率的に処理
- 管理パフォーマンスの改善 - より速い注文管理画面
有効化する方法:
WooCommerce > 設定 > 高度な設定 > 機能に移動- "高パフォーマンス注文ストレージ"を有効にする
- 移行プロセスに従う
詳細を学ぶ:
サーバー監視のベストプラクティス
1. 定期的なパフォーマンスチェック
- 週間レビュー - パフォーマンストレンドのためにログを確認
- ベースライン測定 - 通常の実行時間を記録
- ピーク時間の監視 - 高トラフィックの期間を監視
2. パフォーマンスアラートを設定
以下の警告サインを監視:
- 一貫して実行時間 > 1000ms
- 長時間サーバー負荷 > 5.0
- ログ内の頻繁なタイムアウトエラー
3. キャパシティプランニング
成長トレンドを追跡:
- レコード数の成長 - 製品、注文、顧客
- パフォーマンスの劣化 - 実行時間がどのようにスケールするか
- リソース使用状況 - CPU、メモリ、ディスク使用量
サーバー最適化戦略
1. WordPress/WooCommerce ベストプラクティス
HPOSを有効化:
- WooCommerceにとっての最も影響力のあるパフォーマンス改善
- 詳細はHPOSセクションを参照
PHP設定(ホストに相談):
memory_limit = 512M
max_execution_time = 300
max_input_vars = 3000
WordPress設定:
// In wp-config.php - limit post revisions
define('WP_POST_REVISIONS', 3);
// Enable WordPress debug logging if needed
define('WP_DEBUG_LOG', true);
2. ホスティングレベルの最適化
オブジェクトキャッシング:
- RedisまたはMemcachedの可用性についてホストに確認
- 多くの管理されたWordPressホストはこれを自動的に提供します
PHPバージョン:
- 重大なパフォーマンス向上のためにPHP 8.0以上を使用
- ほとんどのホストでは簡単にPHPバージョンを切り替えられます
サーバーリソース:
- 十分なRAMを確保する(最小1GB、できれば2GB以上)
- SSDストレージは従来のドライブよりもデータベースパフォーマンスが大幅に向上します
助けを求めるべき時
最適化に努めても以下の現象が見られる場合は、ホスティングプロバイダーまたはWordPress開発者に連絡してください。
- サーバー負荷が一貫して> 8.0
- 単純な操作に対する実行時間が> 5000ms
- メモリエラーが頻繁にログに現れる
- データベースクエリが一貫して> 2秒かかる
提供する内容:
- ログのサーバーメトリック
- アクティブなプラグインのリスト
- サーバー仕様(CPU、RAM、ストレージタイプ)
- WordPressおよびWooCommerceのバージョン
関連ドキュメント
- ログ - サーバーメトリックへのアクセス方法と解釈
- チェックアウトパフォーマンス - 支払い処理の最適化
- エラーコード - パフォーマンス関連のエラーコードの理解
- トラブルシューティング - 一般的なトラブルシューティングガイド