私は非常に大きなxpagesプロジェクトを持っており、プロジェクトにいくつかのjarを追加しました（プロジェクトエクスプローラーを介して9つのjar）。これらのjarファイルをクラスパスに追加すると、すべてのxpageまたはカスタムコントロールをDDEに保存するのに25秒かかります。これはクレイジーです（非常に高速なiCore7コンピューター、8 GBのRAMがあり、ラップトップで実行されているローカルDominoサーバーで作業しています...すべて最新8.5.3）。
これらのjarファイルをクラスパスから削除すると、保存時間が1秒未満に戻ります。これらのjarファイルをクラスパスに追加すると、保存時間が最大25秒増加します。それは正常な動作ですか？まだjarファイルを使用しているときにこれを回避するにはどうすればよいですか？
Jar を NSF ファイルに保存する場合、Notes/Domino はコードをコンパイルする前に Jar を切り離してクラスパスに追加する必要があります。これは呼び出されるたびに行われ、サーバー上にある場合は、デタッチする前にクライアントに転送する必要があります。
いくつかの小さな瓶では、これは問題ではありません (使用頻度によって異なります)。ただし、頻繁に呼び出される多数の jar がある場合は、代わりにそれらを「lib/ext」フォルダー (例: c:\notes\jvm\lib\ext) に配置する必要があります。
このようにして、クライアント/サーバーの起動時に一度だけメモリにロードされます。
これが起こっているかどうか教えてください。SPR が存在するかどうかを確認します。
同様の問題を抱えているアプリケーションを開発しているここの人たちと話をしました。彼らは、特定の瓶がサイト全体の速度を低下させていると述べました。たぶん、それらを個別に追加してみて、どれがアプリケーションの速度を低下させているかを確認することができます。
JAR をサーバーからクライアントに転送することによって遅延が発生する場合 (Simon O'Doherty が説明したように)、アプリケーションのローカル レプリカで開発することを検討してください。
大規模なアプリの場合、私は常にそのように作業します。ローカル レプリカで開発し、そのローカル レプリカをビルドまたはクリーンアップしてから、(ローカルまたはリモート) Domino サーバーでアプリケーションを更新します。
もう 1 つのヒント: この方法で開発した場合、HDD を SSD に交換するとパフォーマンスが大幅に向上します。
ここで興味深い観察をしました。Simon D'Oherty のアドバイスに基づいて、すべての jar ファイルを lib/ext に移動したところ、xpage またはコントロールの保存時に突然遅延がなくなりました。jar を 1 つでもデータベースに戻すと、'Building workspace' メッセージで遅延が発生します。すべてを lib/ext に移動すると、「Bulding workspace」メッセージが表示されなくなり、遅延が発生しなくなりました。しかし、アプリケーションを実行しているすべての開発者とサーバーがこれらすべての jar を保持する必要があり、これを維持することはほとんど不可能であるため、この方法で作業するのはかなり面倒です。IBMはデータベースでこれを修正する必要があります!!