2019/08/18 07:57 JST

Geeklog Japan Forums

アップグレードでテーブル構造が変わって参照するテーブル数が増える場合の対応


状態: オフライン

OMAL

Forum User
Active Member
登録日: 02/14/18
投稿数: 45
よろしくお願いします。
昔のギークログをバージョンアップするとテーブル構造が変化することについての質問です。

昔のギークログでカスタム関数でgl_storiesのsidを拾ってtopicと照合するような関数を使っていた場合、tidを介してテーブルを2つ参照しています。
これをバージョンアップすると、tidを直接介せなくなるので、gl_stories,gl_topic_assignment, gl_topicsの3つのテーブルを検索することになります。
単純に計算すると、gl_storiesのsidの行数と、それ以上の行数を持つgl_topic_assignmentの両方を回すことになるので、処理が重くなると思うのです。
実際に、10倍ほど重くなっています。5msだった処理が、50msほどかかってしまいます。これでも対処した方で、手を全く加えてなかった時は500ms以上かかりました。

皆さんはこの辺、どう対応されたのでしょうか?

状態: オフライン

Ivy

Site Admin
Admin
登録日: 01/01/04
投稿数: 5924
場所:Tokyo
OMALさん、
かなり大量の記事があるサイトなのですね。

tidを介して1対1で対応しておらず、処理時間は以前よりかかっていると思いますが、目立って遅くなったという感覚がないのは、件数の違いでしょうか。

GeeklogもPHP7に対応し、全体の処理速度が向上したことでカバーしている傾向はあると思います。

状態: オフライン

OMAL

Forum User
Active Member
登録日: 02/14/18
投稿数: 45
まだテスト段階ですが、この件、解決しそうです。
問題のポイントに気づいたのは、シンプルなselect文で、gl_storiesのsidを検索する場合とgl_topic_assignmentsのidを検索する場合でパフォーマンスの計測結果に大きな差が出た時です。どちらもindexされていました。
一番のネックは、インデックスの順序だったようで、gl_topic_assignmentsに対し、show create tableをかけてみると、indexの順番が、tid, type, idの順になっていました。
問題となっているカスタム関数で実際にwhere句で照合するのはこのidとgl_storiesのsidで、これらの数が膨大なので、idのindex順を上げました。具体的に言うと、tid, type, idの順で作られていたgl_topic_assignmentsのキーを、type,id,tidと変更しました。typeを一番にしたのは、type='article'でまず絞ることを想定してです。
この変更後、最適化をかけてから、処理時間を計測し直しました。すると、10ミリ秒以下(2ms等)のスピードとなりました。
この変更により、このカスタム関数のパフォーマンスは確保できそうです。
ただ、複合indexの順序を変更したことで別のコアシステムのところでパフォーマンスダウンが出るのかどうかは不明です。
どなたかご存知でしたらアドバイスお願いします。

時刻はすべて JST , 現在の時刻は 07:57 AM

  • 通常
  • 注目トピック
  • ロック済
  • 新着
  • 注目トピック 新着
  • ロック済トピック 新着
  •  ゲストユーザの投稿を見る
  •  ゲストユーザ投稿可能
  •  一部のHTMLを許可
  •  バッドワードをチェック