---
sourceDocument: Yokohama 従業員サービス管理 (ESM)
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/yokohama/employee-service-management

 Release :

    - yokohama

ft:locale :

    - ja-JP

ft:publication_title :

    - Yokohama 従業員サービス管理 (ESM)

ft:clusterId :

    - emplsm

bundleId :

    - emplsm

workflow :

    - Employee


---

# ポータル並行処理性

# ポータル並行処理性 {#ariaid-title1}

* リリースバージョン: Yokohama
* 
* 更新日 2025年04月25日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：3分

パフォーマンスを向上させ、ポータルの同時実行コンテンツを強化する方法について説明します。

ポータルパフォーマンス機能は、ユーザーの機能を犠牲にすることなく高同時実行コンテンツをシームレスに改善し、より多くのユーザーがコンテンツに同時にアクセスできるように、可用性と柔軟性を向上させます。  
注:  
この機能は、 会社のイベントで、\[ 大量のトラフィックに対してパフォーマンスを最適化する\] が選択されている場合にのみ機能します。

ポータルパフォーマンスの管理の詳細については、「 [ポータルパフォーマンスの管理](https://servicenow-prod.fluidtopics.net/38dnLIDO_wRZEFdeg64tVw "ポータルのロード時間を短縮し、ポータルの表示を向上させる方法を見つけます。")」を参照してください。
{#ce-portal-concurrency-performance__table_hdp_k1y_cfc__entry__1}{#ce-portal-concurrency-performance__table_hdp_k1y_cfc__entry__4}

| sn_cd_precomputed_audienceリスト |||
| 列名 | 列のタイプ | 説明 |
|-|-|-|
| ユーザー | 参照 (sys_user) | この事前計算レコードに関連付けられたユーザー |
| コンテンツ | 参照 (sn_cd_content_base) | ユーザーがアクセスできるコンテンツ |
| ドメイン | システムドメイン | ドメインセパレーションフィールド |
[表 : 1. 事前計算された対象者]

{#ce-portal-concurrency-performance__table_hdp_k1y_cfc}  
注:  
テーブル内のデータは同期フローでのみ追加する必要があり、手動で変更しないでください。

## 自動同期トリガーのフローを事前計算 {#ce-portal-concurrency-performance__section_b3g_m4p_52c}

1. 24 時間ごとの 00:30 に実行されるようにスケジュールされた、「 コンテンツ公開:会社イベントの対象者の事前計算 」というタイトルの新しいスケジュール済みジョブが存在します。
2. ジョブがトリガーされたら、現在の 1 時間から次の 30 時間までのトラフィックの多い会社イベントをすべて確認します。
3. 見つかったイベントごとに対象者を事前に計算して、ユーザーとコンテンツを事前計算テーブルに記録します。
4. 事前計算フロークリーンアップについては、「 コンテンツ公開:会社イベントの対象者の事前計算 」というタイトルのスケジュール済みジョブを確認します。
5. ジョブがトリガーされたときに、既存の事前計算対象者レコードの中で一意のイベントを計算します。
6. 計算された会社イベントごとに、イベントが終了したかどうかを確認します。終了した場合は、それに関連付けられているすべての事前計算レコードを削除します。
{#ce-portal-concurrency-performance__ul_hrv_s4p_52c} {#ce-portal-concurrency-performance__table_ktn_r2z_cfc__entry__1}

| フローの例を事前に計算 ||
|-|-|
| 完全手動同期 | システムアドミンは、スケジュール済みジョブ 「コンテンツ公開:会社イベントの対象者の事前計算 」を手動で実行して、事前に計算された対象者テーブルを完全に同期できます。 |
| 部分的な手動同期 | コンテンツアドミンは、 sn_cd_company_event テーブルを参照し、特定のイベントを見つけて、\[ このコンテンツの対象者を事前計算 \] UI アクションを選択できます。 注: これにより、コンテンツ対象者に属さなくなったユーザーのみが削除され、直前のケースでアクセス権が必要なユーザーのみがコンテンツを表示できるようにするために使用されます。 |
[表 : 2. 手動同期トリガー]

{#ce-portal-concurrency-performance__table_ktn_r2z_cfc}

## 事前計算された対象者チェックフロー {#ce-portal-concurrency-performance__section_sdx_ywt_52c}

1. ユーザーが、高トラフィックパフォーマンスの最適化を有効にして会社のイベントにアクセスします。
2. パフォーマンス最適化チェックが開始されました。
   1. コンテンツ ID と現在のユーザー ID を使用して対象者テーブルを照会します。
   2. ユーザーが見つかったら、記事のロードを開始します。
   3. ユーザーが見つからない場合は、標準アクセスチェックを開始します。
   {#ce-portal-concurrency-performance__ol_lkn_tq1_dfc}
{#ce-portal-concurrency-performance__ol_st5_dcy_cfc}

## 標準対象者チェックフロー {#ce-portal-concurrency-performance__section_clr_zby_cfc}

注:  
標準的な対象者チェックは現在のステータスであり、事前計算が使用されていない場合でも引き続き使用されます。

1. ユーザーが会社のイベントにアクセスします。
2. アクセスチェックが開始されます。
   1. 表示中のコンテンツに関連付けられたスケジュールごとにスケジュールコンテンツテーブルを照会します。
   2. スケジュールコンテンツレコードごとに、関連する各対象者を反復処理します。
   3. 対象者ごとに、run.isUserInAudience() を行います。これにより、現在のユーザーが対象者に含まれているかどうかが評価されます。
   4. ユーザーが見つかったら、記事のロードを開始します。
   5. ユーザーが見つからない場合は、各スケジュールコンテンツレコードに関連付けられた各対象者を反復処理します。
   6. ユーザーが見つからない場合は、空ステータスの記事の詳細ページを表示します。
   {#ce-portal-concurrency-performance__ol_pyf_br1_dfc}
{#ce-portal-concurrency-performance__ol_wp1_2cy_cfc}