問題
- なぜキャッシュではなくデータベースに journalarticle の呼び出しが多いのか？
Environment
- Liferay DXP [すべてのバージョン］
解決策
-
データベース内の
JournalArticleオブジェクトはウェブコンテンツ記事を表します。そのため、Liferayが何らかの理由でウェブコンテンツ記事を取得する必要がある場合、キャッシュ内でウェブコンテンツ記事を見つけることができなければ、このクエリはいつでも実行されます。 Liferayがウェブコンテンツ記事をフェッチする必要がある多くの理由があるので、このクエリが実行される可能性のある全てのシナリオを列挙するのは非常に難しいでしょう。 しかし、非網羅的なリストとしては以下のようなものがある：-
ユーザーはサイト管理 > コンテンツ & データ > ウェブコンテンツメニューにアクセスしています。 この場合、 n
JournalArticleまでのクエリーを実行する必要があります。 n は、ユーザーがページ上で見るウェブコンテンツの量です。 -
ユーザーがウェブコンテンツを編集しようとした
-
ユーザーは、ウェブ・コンテンツをレンダリングするように構成されたウェブ・コンテンツ表示ポートレットおよび/またはアセット・パブリッシャ・ポートレットを含むページを訪問します。 この場合、 n
JournalArticleまでのクエリーを実行する必要があります。 n は、ページ上のポートレット全体で表示されるウェブコンテンツの数です。 -
ウェブコンテンツの記事が有効期限またはレビュー期限に違反しており、その記事の有効期限を切ったり、レビュー通知を送信するための自動処理が実行されている。
覚えておいてほしいのは、これは包括的なリストではなく、ここで役立つかもしれない最も一般的なシナリオのいくつかに過ぎないということだ。 また、Liferayは常に最初にキャッシュから記事を取得しようとし、記事がキャッシュで見つからなかった場合にのみ、
JournalArticleクエリを実行することを覚えておいてください。 -
追加情報
-
JournalArticleがキャッシュにない最も一般的な理由がいくつかあります:
- JournalArticleはクエリーの時点ではまだデータベースから読み込まれていませんでした。、JournalArticleごとに起動後に一度だけ発生し、その後ポータルが再起動するまで二度と発生しないはずです。 しかし、ユーザーが頻繁に新しいJournalArticleを追加している場合は、その可能性があります。
-
すべてのJournalArticleを保持するにはキャッシュが小さすぎるため、JournalArticleが以前にキャッシュから削除されました。 これは、データベース内のJournalArticleの数が、キャッシュ・コンフィギュレーションで定義された
maxElementsInMemoryの値を超えた場合に発生する可能性があります。 これにより、JournalArticlesのキャッシュ・サイズが大きくなるたびにキャッシュから削除される。 もしそうなら、maxElementsInMemoryの値が大きくなるようにキャッシュをチューニングし、おそらくJVMの割り当てメモリーも増やして、キャッシュ・サイズの増加を補うことで解決できるだろう。 -
JournalArticleが長時間使用されなかったため、キャッシュから失効しました。 これは、JournalArticleが一度もフェッチされずに、キャッシュ・コンフィギュレーションで定義されている
timeToIdleSeconds値よりも長い間、キャッシュ内でアイドル状態になっている場合に発生する可能性があります。 もしこれが問題であれば、timeToIdleSecondsの値を増やすことで、ユーザーはキャッシュを調整することができる。 - JournalArticleは更新されたため、以前にキャッシュから削除されました。 JournalArticleが更新される度に、全てのキャッシュから即座に削除され、次にデータベースから再フェッチされなければなりません。 JournalArticlesを頻繁に更新するようなカスタムコードや自動化されたプロセスがある場合、これが原因かもしれません。
- 上記の情報は、製品の観点から 、こちらの キャッシュ構成入門。 Liferayのサポートは、ユーザーがどのようなキャッシュ設定値を設定すべきかについて、具体的な提案や推奨を提供することに限られていることに注意してください。 しかし、私たちは"global services team"という別のチャンネルを持っています。