1

そのため、PDF 処理機能を提供するこの WCF サービスがあります。現在、プレーンなバイト配列 ( byte[]) を受け入れて返していますが、これは、常にすべてをメモリに読み込んでいることを意味し、ストリームを処理する場合でも、それらをバイト配列に ToArray() する必要があります。問題は、メモリ不足の問題とヒープの断片化を引き起こしていることです。

あまり多くのメモリを使用しないように最適化するには、次の 2 つの選択肢があります。

  • ストリームを使用します。魅力的ではありますが、PDF ツールキットで処理するためにディスクに永続化する必要があるかもしれません。また、バインディングの数が限られていること、および二重ストリーミングとパラメーターの数が制限されていることを考えると、これは非常に厄介な戦略でもあります。
  • UNC ファイル パスをやり取りします。有望に思えますが、使用後に誰かがファイルをクリーンアップする必要があるため、状況が複雑になります。

リソース (メモリ、ネットワーク、ファイル システム) の使用を最適化するという点で、最良の結果を達成する代替手段はどれですか?

4

2 に答える 2

3

古い学校ですが、「UNCファイルパスを前後に渡す」を使用します。幸いなことに、私たち開発者はこのアプローチについて数年の経験があります (1980 年頃の Unix バージョン 7 の印刷スプーラを参照してください)。

于 2013-01-14T21:25:00.200 に答える
2

UNCファイルパスオプションも選択します。これは、ユーザーがアップロードしたファイルをWebサーバーからアプリケーションサーバー経由でSharePointに転送するときに使用しました。WebサーバーはファイルパスをAppServerに渡し、AppServerはファイルを取得してSPにロードします。WebサーバーからAppServerへのWebサービス呼び出しを介してファイルをバイト配列として渡す方がはるかに優れたオプションでした。

「後で誰かがファイルをクリーンアップする必要がある」に関して、サービスが常にクリーンアップを実行しない可能性がある場合、たとえば例外があった場合は、いつでもバックアップ計画を立てて、スケジュールされたタスクでPowerShellスクリプトのような単純なものを使用できます。以前に削除されているはずの古いファイルを削除します。

ただし、考慮すべきことの1つは、ファイル名が衝突する可能性です。私たちの場合、2人のユーザーが同じ名前の別々のファイルをアップロードすることが可能であったため、適切なファイルが適切なSPフォルダーに配置されていることを確認する必要がありました。これを解決するには、ファイルをローカルに保存したWebサーバーを使用し、ファイルの名前をGUID名に変更してから、新しい名前をAppServerに渡します。元のファイル名はメタデータとしてAppServerに送信され、SPにロードする前にファイルの名前を元の名前に戻すことができました。

于 2013-01-14T22:40:46.790 に答える