サーバーパフォーマンス
サーバーパフォーマンスは、WCPOS アプリケーションの速度と応答性に直接影響します。POS は多数の REST API 呼び出しを行うため、サーバーの応答時間が主なボトルネックです。POS の速度はホスティングの品質に大きく依存します。このガイドでは、組み込みのメトリクスとトラブルシューティング手法を使用して、サーバーパフォーマンスを監視、診断、最適化する方法を説明します。
サーバーの最小要件
本番環境で応答性の高い POS を利用するには、少なくとも次の構成を推奨します。
共有ホスティングでは、多数の同時 API 呼び出しを行う POS ワークロードに対して、PHP ワーカー数やメモリが不足することがよくあります。本番環境で POS を使用する場合は、VPS またはマネージド WordPress ホスティングを強く推奨します。WordPress.com のマネージドホスティングでも REST API の互換性問題が知られています（大規模なカタログで商品が 9〜10 点しか表示されないユーザーもいます）— 完全な互換性を確保するには、セルフホスト型の WordPress.org を推奨します。
コミュニティで検証された最適化スタック
ユーザーからは、この組み合わせで POS のパフォーマンスが最も高いと報告されています:
- MariaDB 11.4（WooCommerce ワークロードでは MySQL より高速）
- HPOS が有効 (下記参照)
- LiteSpeed または Redis オブジェクトキャッシュ
- NVMe ストレージ
- PHP OPcache が有効
503 エラー
503 Service Unavailable は POS のバグではありません — サーバーがリクエストを処理できなかったことを意味します。確認項目:
- サーバー負荷と利用可能なリソース
- PHP ワーカー (枯渇している可能性があります)
- PHP メモリ上限 — 256 MB 以上に増やしてください
- 利用中の Web ホストのサーバーログ (ホストに問い合わせてください。アプリケーションから見えない情報を確認できます)
WooCommerce バージョン互換性
WooCommerce の更新により、まれに POS が動作しなくなることがあります。WooCommerce は必ず先にステージングサイトで更新し、最新の互換性修正が含まれるように WCPOS を常に最新の状態にしてください。
既知の問題:
- WooCommerce 10.5.0 — POS での商品読み込みに問題が発生しました（症状: 約 10 件の商品しか表示されず、バーコードスキャンと検索が機能しなくなる）。また、実験的な商品キャッシュが導入され、postmeta の肥大化やメモリ不足を引き起こす可能性があります。修正: WCPOS を最新バージョンに更新してください（修正とクリーンアップ移行が含まれています）。または WooCommerce を 10.4.3 に戻してください。
WooCommerce の更新で POS が動作しなくなった場合は、プラグインの WordPress.org ページにある Advanced タブから WooCommerce を前のバージョンに戻し、問題を報告してください。
サーバーメトリクスの理解
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の場合、全コアが使用されていることを意味します
- 継続的な負荷と一時的な負荷 - 短時間の急上昇は正常ですが、継続的な高負荷は問題を示している可能性があります
- パフォーマンスの方が重要です - 高負荷でも応答性の高いサーバーは、低負荷でも遅いサーバーよりも優れています
注意すべき点:
- 実行時間が増加している
- 負荷が理由なく継続的に増加している
- 高負荷と遅い実行時間の両方が同時に発生している
パフォーマンスベンチマーク
実行時間の目安
| 操作 | 良好 | 許容範囲 | 不良 | 重大 |
|---|---|---|---|---|
| 商品の取得 | < 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 を最新の状態に保つ - コアの更新にはデータベース最適化が含まれることがよくあります
- 投稿リビジョンを制限 -
define('WP_POST_REVISIONS', 3);を wp-config.php に追加します
3. プラグインの干渉
症状:
- プラグイン更新後に突然パフォーマンスが低下する
- 特定の操作が他の操作より大幅に遅い
- サーバー負荷は通常なのに実行時間が長い
トラブルシューティング:
- ステージングでテスト - WooCommerce と WCPOS 以外のすべてのプラグインを無効化する
- ベースラインを測定 - 最小限のプラグイン構成で実行時間を記録する
- 段階的に有効化 - プラグインを1つずつ追加して原因を特定する
- プラグインフックを確認 - WooCommerce アクションにフックしているプラグインを探す
問題が起きやすい一般的なプラグイン:
- 商品操作中に負荷の高い SEO プラグイン
- 複雑な在庫管理システム
- リアルタイム分析/トラッキングプラグイン
- 品質の低いカスタムプラグイン
4. WordPress/WooCommerce の設定
症状:
- パフォーマンスが安定しない
- ログにメモリ関連のエラーが記録される
- 管理ダッシュボードが遅い
最適化チェックリスト:
- PHP バージョン - パフォーマンス向上のため PHP 8.0+ を使用する
- WooCommerce HPOS - 高性能注文ストレージを有効化する (下記参照)
- WordPress キャッシュ - 利用可能な場合はオブジェクトキャッシュを有効化する
- WooCommerce 設定 - 商品画像サイズを最適化する
WooCommerce 高性能注文ストレージ (HPOS)
HPOS は、WooCommerce に対して実施できる最も重要なパフォーマンス改善の 1 つです。 注文を WordPress の投稿テーブルではなくカスタムデータベーステーブルに保存するため、注文数の多い店舗でパフォーマンスが大幅に向上します。
メリット:
- 注文クエリの高速化 - 最適化されたデータベース構造に注文を保存
- データベース負荷の軽減 - 注文を投稿やページから分離
- スケーラビリティの向上 - 大量の注文を効率的に処理
- 管理画面のパフォーマンス向上 - 注文管理画面を高速化
有効化する方法:
WooCommerce > 設定 > Advanced > Featuresに移動します- "高性能注文ストレージ" を有効化します
- 移行プロセスに従う
詳細情報:
サーバー監視のベストプラクティス
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 ストレージは、従来のドライブよりもデータベースのパフォーマンスを大幅に向上させます
ホスティング別の注意事項
一部のホストや CDN では、POS が WooCommerce REST API に到達できるように設定が必要です:
| ホスト / サービス | 問題 | 修正 |
|---|---|---|
| ゴーダディ | ウェブサイトファイアウォールが /wp-json/ REST API 呼び出しをブロックします（"Received 'undefined'" のようなエラー） | Website Security > Firewall > 設定 > Access Control > Allow URL Paths → /wp-json/ を追加 |
| WP エンジン | REST API を明示的に有効化する必要があります | REST API を有効化します。必要に応じて、ファイアウォールで API エンドポイントを許可リストに追加します |
| クラウドフレア | REST API リクエストをブロックする場合があり、API レスポンスをキャッシュすることもあります | ファイアウォールルールを確認します。/wp-json/* のキャッシュをバイパスするページルールを追加します |
| WordPress.com（ワードプレス・ドットコム） | REST API / 商品読み込みの互換性の問題（9〜10 個の商品しか表示されない） | 完全な互換性を得るには、自己ホスト型の WordPress.org を使用します |
| 共有ホスティング | 同時 POS 呼び出しに対して PHP ワーカー数が少ない / メモリが不足している | VPS またはマネージド WordPress ホストへ移行します |
セキュリティプラグイン（Wordfence など）も同様の方法で REST API をブロックする場合があります。完全な一覧と修正方法については、プラグインの競合を参照してください。
HTTP 414 — URI が長すぎます
大きなカート、またはチェックアウト URL に含まれるアクセストークンにより、サーバーの URL 長制限を超える場合があります（チェックアウトリクエストは GET を使用します）。これはブラウザー固有の場合があり、ブラウザーキャッシュによって悪化することがあります。
回避策: まずブラウザーキャッシュをクリアし、その後サーバーの URL 長制限を引き上げます:
- Apache:
LimitRequestLine 65536でhttpd.confを設定 - Nginx:
large_client_header_buffers 4 65536;でnginx.confを設定 - 設定にアクセスできない場合は、ホスティングプロバイダーに調整を依頼してください。
サポートを依頼するタイミング
次の場合は、ホスティングプロバイダーまたは WordPress 開発者に連絡してください:
- 最適化を行ってもサーバー負荷が常に > 8.0
- 単純な操作で実行時間が > 5000ms
- メモリエラー がログに頻繁に表示される
- データベースクエリーに常に > 2 秒かかる
以下を提供してください:
- ログから取得したサーバーメトリクス
- 有効なプラグインの一覧
- サーバー仕様（CPU、RAM、ストレージの種類）
- WordPress と WooCommerce のバージョン