WPML 3.5には、文字列翻訳への大きな変更が含まれていました。公開後、開発中には現れなかったいくつかのケースについて把握しました。その後のアップデートですべての問題に対処し、パフォーマンスをさらに向上させています。
WPML 3.5以降の修正
- icl_stringsテーブルにdomain_name_context_md5カラムが存在しない場合のキャッチされない例外の修正
- パーマリンクのフィルタリング時に「Argument ID must be numeric and greater than 0」というメッセージを伴う致命的なエラー：Uncaught exception 'InvalidArgumentException'の修正
- アップグレード中に発生する致命的なエラーの修正：WordPress database error: specified key was too long; max key length is 1000
- PHP 5.2での致命的なエラー：Declaration of WPML_Post_Element::get_type() must be compatible with that of WPML_Translation_Element::get_type()の修正
- PHP 5.3以前での警告を回避するための先頭のバックスラッシュ\の削除
スピードの改善
どの文字列がどのページに表示されるかを保存する新しいテーブルに、いくつかの調整を加えました。これらの変更により、テーブルサイズが大幅に縮小され、パフォーマンスが向上し、メモリ消費量が削減されます。
- 冗長性のある1つの大きなテーブルを、2つの小さく効率的なテーブルに分割
- テーブルインデックスの最適化
- ページ選択を変更する引数のホワイトリストを使用することによる、URL引数を使用するサイトでのテーブルの肥大化の制限
結果
バージョンアップデート中に、自社サイトのパフォーマンスを測定しました。負荷が減少し、その後（テーブルインデックスが最適化されていなかったときに）上昇し、現在では元の状態よりも低下していることがわかります。
これらのグラフの絶対値は、曜日の異なる日に測定されたため、それほど重要ではありません。金曜日のトラフィックは月曜日よりもはるかに少なくなります。変化を理解するには、セグメント間の比率に注目してください。当初、icl_stringsへのアクセスには、投稿の取得とほぼ同じ時間がかかっていたことがわかります（これは良いことではありません）。現在、WPMLのすべてのデータベースアクセスは、平均して投稿クエリの1/3の時間がかかっています。WPMLは大量の文字列を読み込む必要があるのに対し、WordPressは少数の投稿を必要とするだけであるため、これは非常に重要です。
次回のより良いプロセス
このアップデートにはWordPress 4.6向けの変更が含まれていたため、完全なパフォーマンス測定を実行できるようになる前にリリースする必要がありました。今後は、パフォーマンスの向上とWordPressの互換性を必ず切り離すようにします。WordPressの新しいバージョンが「リリース候補」に達し次第、互換性の変更のみを含むマイナーリリースを行います。バグ修正や互換性アップデートとは無関係に、より時間のかかるパフォーマンスの変更を実行するための時間を確保し、その結果に十分に満足できた後にのみリリースします。
WPMLの次回のリリースでも、引き続き安定性とパフォーマンスに重点を置きます。WPMLを実行しているサイトの99%は現在スムーズに動作していますが、Webサーバー、PHP、またはデータベースの「独自の」構成を使用しているサイトがいくつかあります。次回のマイナーリリースでは、これらに対処する予定です。また、管理画面とフロントエンドの両方をより軽量化する、いくつかのパフォーマンス最適化も含める予定です。
フィードバック
ご質問、アイデア、ご提案がありましたら、コメントを追加してください。皆様からのフィードバックをお待ちしております。必要な機能を提供できるよう最善を尽くします。
