メインコンテンツにスキップ
バージョン: 1.x

サーバーパフォーマンス

サーバーパフォーマンスは、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. 一時的なもの - 短時間のスパイクは正常であり、持続的な高い負荷は問題を示す可能性があります
  • パフォーマンスがより重要 - 高い負荷のある応答性の高いサーバーは、低い負荷のある遅いサーバーよりも優れています

注意すべき点:

  • 時間の経過とともに増加する実行時間
  • 説明なしに継続的に成長する負荷
  • 高い負荷と遅い実行時間の両方

パフォーマンスベンチマーク​

実行時間のガイドライン​

操作良い許容可能悪い重大
製品のフェッチ< 100ms100-500ms500ms-2s> 2s
注文の作成< 200ms200-800ms800ms-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: ログを監視する​

  1. ナビゲーションドロワーからログを開きます
  2. 遅い操作を実行します（製品の同期、注文の作成など）
  3. 対応するログエントリを探します
  4. メトリクスを見るためにコンテキストを展開します

ステップ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. プラグインの干渉​

症状:

  • プラグインの更新後の突然のパフォーマンス低下
  • 特定の操作が他の操作よりも大幅に遅い
  • 通常のサーバーロードでの高い実行時間

トラブルシューティング:

  1. ステージングでテストする - WooCommerceとWCPOSを除くすべてのプラグインを無効にします
  2. ベースラインを測定する - 最小限のプラグインでの実行時間を記録します
  3. 徐々に有効にする - プラグインを1つずつ追加して加害者を特定します
  4. プラグインのフックをチェックする - WooCommerceアクションにフックするプラグインを探す

一般的な問題のあるプラグイン:

  • 製品操作中の重いSEOプラグイン
  • 複雑な在庫管理システム
  • リアルタイム分析/トラッキングプラグイン
  • 不適切にコーディングされたカスタムプラグイン

4. WordPress/WooCommerceの設定​

症状:

  • 不安定なパフォーマンス
  • ログ中のメモリ関連のエラー
  • 遅い管理ダッシュボード

最適化チェックリスト:

  • PHPバージョン - より良いパフォーマンスのためにPHP 8.0以上を使用します
  • WooCommerce HPOS - High-Performance Order Storage を有効にします（以下参照）
  • WordPressキャッシング - 利用可能であればオブジェクトキャッシングを有効にします
  • WooCommerceの設定 - 製品画像サイズを最適化します

WooCommerce High-Performance Order Storage (HPOS)​

最大のパフォーマンスの勝利

HPOSはWooCommerceのために行える最も重要なパフォーマンス改善の1つです。 これは、注文をWordPressの投稿テーブルの代わりにカスタムデータベーステーブルに保存し、多くの注文を持つストアのパフォーマンスを劇的に改善します。

利点:

  • 迅速な注文クエリ - 最適化されたデータベース構造に保存された注文
  • データベースの負荷の軽減 - 投稿/ページから注文を分離します
  • より良いスケーラビリティ - 大量の注文を効率的に処理します
  • 管理パフォーマンスの改善 - より迅速な注文管理画面

有効化方法:

  1. WooCommerce > 設定 > 高度な設定 > 機能に移動します
  2. "High-Performance Order Storage"を有効にします
  3. 移行プロセスに従います

詳細を学ぶ:

サーバー監視のベストプラクティス​

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のバージョン
ログサーバーメトリクスへのアクセスと解釈方法
チェックアウトパフォーマンス支払い処理を最適化します
エラーコードパフォーマンスに関連するエラーコードを理解します
トラブルシューティング一般的なトラブルシューティングガイド