3
2
1

Confluenceで安定した稼動を求める場合に、利用すべきでないマクロや、制限を設けたほうがよいことなど、何でもいいので教えてください。大規模なお客様ではこうしてます!的なお話を聞けたらうれしいです。

    Commentコメントを追加...

    3 回答

    1.  
      3
      2
      1

      ご質問の大規模をどこからを対象とするかにもよりますが...

      500人以上でご利用になられている、もしくは 100万ページ(履歴を含む)を超えてきたら大規模の部類の感覚ですかね...


      私も長く運用してきていますが、安定してる高速なConfluenceが欲しいです...落ちるのだけはご勘弁を...

      そういうのであれば、やっぱりConfluence DataCenter も検討なんですかね!

       

      まずは、Atlassian社のPerformance Tuningガイドは必読です。

      つぎに、https://jira.atlassian.com の Confluenceプロジェクトで Performance コンポーネントにある未解決課題リストです。

      Atlassianも認識しているような問題がリスト化されているので、参考になるかと思います。


      またユーザで運用してきた経験に基づく情報がAtlassianユーザー会で公開されていますので、ご参考までに。

      Yahoo! JAPAN 高橋様 

      IIJ様 高野様

      楽天→リクルートライフスタイル 梶原様

      余談ですが、次回のユーザ会はYahoo! JAPAN様で開催するので、ぜひぜひ直接質問していただければと思います。

       ↓参加申し込みはこちらより

      第15回 Tokyo Atlassian ユーザーグループ @Yahoo!Japan #augj

      さて、経験上大規模Confluenceパフォーマンスの原因になりやすいのは4点に分類されます。

      1. インデックス系処理
      2. ページ権限系処理
      3. ページ移動、Export処理系
      4. 連携処理系


      1.インデックス系処理

      Confluenceでは、参照の処理を高速化するためにDB参照ではなくLuceneという検索インデックスを参照データとして利用することがあります。
      具体的なインデックス内容としては、ページ内容(ページ内容、コメント、権限)、添付ファイル(一部ファイルはファイルの中身も)、ユーザー情報、アドオンによってはアドオンでの情報(Team CalendarのカレンダーID)等です。
      それらを追加・更新するとWrite(インデックス更新処理)が走ります。
      参照では、検索はもちろん、ダッシュボード、検索結果マクロ、最近の更新、ユーザー情報…など
      VersionUPしていくにつれて、ページ表示するだけでも知らずに利用されていることが多くなっています。
      Luceneは非常に高速ではあるのですが、更新と参照が繰り返す場面には、その処理が衝突する場面などはどうしても性能劣化してくることがあります。Confluence全体のページ数などインデックスサイズが大きくなるにつれて、その傾向が顕著に表れます。
      そのため、大規模を予測されるのであればインデックス量を少なくするような施策がよいと思います。
      具体的にはConfluenceは、ページに添付されている Word、Excel、PPT、PDF形式の中身までインデックスを作成してくれるのですが…添付ファイルの量にもよりますが、テキスト変換が必要で遅い処理にも部類します。
      (警告) よく、ファイル内でフォントが見つからないなどエラーにもなっています...
      対策としては、下記KBの通りOffice系のコンテンツ内容まではインデックスしないようにすることを実施されているお客様は多いで印象です。コンテンツ内容では出来なくなりますが、ファイル名での検索はできます。
      あとは、インデックス更新キューが5秒間隔で処理しているので、更新が非常に多いところでは少し間隔調整してみるのもよいかもしれません。

      2.ページ権限系処理

       
      ページ権限処理は、 kumai-san, のご認識の通り、Page Tree Macro, Children Display、サイドバーなどのページツリー形式の表示です。
      ページ権限では親子の階層構造をチェックする必要があり、階層構造が深くなるにつれて重くなるような傾向です。
      またサイドバーなどでは、1ページ毎にチェックしている処理部分もあります(最新Versionの5.8では、まだ改善しているか確認していないですが)
      実装としてはキャッシュなどを使って高速化しているようですが、プロファイルすると単体の処理は早いのですが、ページ数が多い場合積み重なると遅い処理になります...(4000ページあるとして、単体が1msだとしても…4000msで4秒です)
      また、ページ権限を修正すると、子のページ権限を修正するためにインデックス更新が大量に発生します...
      ページ権限を変更して、しばらく応答が返ってこなかったら、その処理が動いているんだと思っていただければと思います。
      (情報) 管理画面のインデックスキューを見れば急増しているのがわかります。
      ページ権限をどうすればよいか?という解には...
      スペース権限で、まずはある程度絞っておくことを推奨します。
      ページ権限は、深い階層構造の親ページで使うのではなく、階層の少ないところでの補完機能として、あまり多用しないことをお勧めします。
      Page Tree Macro, Children Displayマクロなどは、最悪OFFすればいいのですが、ページ権限に関しては機能を消すことはできないため、ユーザー教育ベースとなります...
      また運用としては、スペースを作ることが気軽である環境が良いかと思います。
      スペース作成が困難のため、既存のスペースであらゆるドキュメントを集めて、ページ権限で管理するようにならないようにするためです…

       

      あとは有名なところで、index(ページインデックス)マクロも遅く

      実装がスペースのページを舐めてHashMapで作っているので...ページ数が多ければその分重いです。

      ページタイトルがアルファベットでしか分類できないので、日本語環境であれば、まず止めてもいい機能かと思います。

      Confluenceのユーザーリストマクロも数万人登録されているConfluenceで、全グループ表示なんてことをした場合、ページの応答が返ってこない可能性があります。

      3.ページ移動、Export処理系

      ページ移動は想像の通り重いです。

      1ページずつなら大した問題ないのですが、数千ページを階層構造を含めて一気に移動をする場合は…相談ベースで移動することを推奨します。

      あとは、スペースレベルのExportも障害の原因になりやすいです。

      スペース管理画面からの、XML、HTML、PDF Exportを無効化に修正してしまうお客様もおられます。

      4.連携処理系

      JIRAなどと連携している場合、たくさんの(100件以上の)課題をConfluenceのページ上に張るとキャッシュしているものの、JIRA側の参照負荷になり、ConfluenceもJIRAに参照しに行っているため、負荷になる場合があります。

      あとは、メール送信などです。

      メール配信で「日々の更新を配信登録」「お勧め更新の配信登録」という機能があるのですが

      数万人のユーザーでご利用になっていると、その分配信することになるので…メール処理が終わらないということもあるかもしれません?

      あとは、OfficeやPDFをページ内でViewできる機能も、その変換処理が重いため、止められるお客様も多いです。

       

      他にも書きたいことがあるような気がするのですが…長くなりそうでまとまっていないのでこのくらいで。

      参考にならないコメントごめんなさい。

        Commentコメントを追加...
      1.  
        4
        3
        2

        大規模ってどの程度かは?で、一概には言えないですけどこんな感じでしょうか...

        Confluence Inline Tasks Plugin

        こんな問題が...

        チェックボックスを連続でクリックすることで、DBコネクションが大量発生して、DBがロック、Confluenceのサービスがダウンする場合がある。

        対応としては...

        編集モードでインラインタスクをクリックするようにする。(操作性は悪いですが編集後に反映されるので...)
        プラグイン無効化
        Confluence5.5.3, 5.5-OD-28で修正されているようなのでバージョンアップ(直っているか確かめたわけではないです...)

        関連情報

        インラインタスクDBのスレッドプールを使い果たす問題
        CONF-28010 Multiple clicks on inline tasks causes Confluence to perform badly due to database thread pool contention

        Page Tree Macro, Children Display Macro

        こんな問題が...

        子孫ページを表示するオプションをオンにした場合に、ページのツリーを遡って権限を取得するSQL処理で時間がかかる場合がある

        対応としては...

        このマクロの利用を運用ルールで制限しない。
        子孫ページ数や階層数を運用ルールで制限する。

        関連情報

        「include excerpt」をONにした場合のパフォーマンス問題
        CONF-31525 Children display macro with include excerpt gives performance issue

        管理者がマクロの深さを制限するようにする要望(won't fixでクローズ)
        CONF-22724 Allow admin to disable the feature of specifying depth in children macro, and always set depth = 1

        Documentation Theme

        こんな問題が...

        Confluence 5.xからデフォルトでサイドバーの表示が強制されるようになり、サイドバーのページツリーの表示がパフォーマンスに悪化につながるケースがある。

        対応としては...

        スペース毎 に「ツリー表示しない」オプションでページツリーを無効化してみる

          Commentコメントを追加...
        1.  
          1
          0
          -1

          Kengo Ohsakiさん

          ありがとうございます!

           

            Commentコメントを追加...