5

APEのmod_xsendfileはCF9のjrun_iis6_wildcard.dllで機能しないため、を使用してファイルを安全に提供する必要があります<cfcontent>。現在の問題は、ファイルのダウンロードが大きい場合、または接続が遅い場合、CF要求を長期間拘束することです。ハード制限を適用する方法がなければ、理論的には、すべての要求がファイルの提供に結び付けられた状態でCFサーバーを停止することができます。

以下の追加のロギング/ロジックを試してみ<cfcontent file="">ましたが、到達して実行されないことに気付きました。 

<cfcontent file="test.mp3">

<!--- won't reach here --->
<cfdump output="console" var="#now()# download done!">

あまりにも多くのcfcontentリクエストを処理することによってCFがダウンするのを避けるために何ができるでしょうか？

更新：朗報です！CF10はAPEのmod_xsendfileで動作します！

4

1 に答える 1

0

解決策 1

制御不能な要因 (「スタック」したスレッド、サービス/サーバーのシャットダウンなど) により、100% 真のアカウンティングが得られる可能性は非常に低いことを考慮すると、次のようにすることができます。

総リクエストのみを追跡したい場合は、ファイルの提供を開始するときにインクリメントするアプリケーション変数を使用できます。次に、コンテンツが完了したら、カウントを減らします。ただし、cflock を使用して、この更新によって問題が発生しないように注意してください。

これをファイルに記録したい場合は、同じことを行うことができますが、ファイルを同時に読み書きするリクエストで問題が発生しないように、cflock でラップします。

SQL を使用している場合は、ファイルを表すテーブルを作成し、フェッチごとにレコードと適切な情報を追加できます

  • ファイル名
  • はい/いいえフィールドのビットとして完了、デフォルトは false
  • ユーザー/クライアント情報
  • 開始日/時刻のデフォルトは今、
  • 終了日時のデフォルトはnull、
  • ステータス「ダウンロード中」
  • その他の情報

返された ID cfcontent を使用してファイルを作成し、完了したら、指定された ID で正しい日付/時刻とステータス「成功」を使用してテーブルを更新し、yes に完了します。

onerror の間、ステータス「エラー [関連するエラーの詳細]」を反映してテーブルを更新し、完了を 1 にすることができます。キャッチオール更新を追加して完了 = 1 に変更するか、そうでないレコードをパージすることは悪い考えではありません。利用可能 (アプリケーションの起動時または一定期間後)

これにより、現在保留中のリクエストの合計 (およびその内容など) をこのテーブルに問い合わせることができます。

ただし、それは実行時間の長いリクエストの問題にのみ対処します。

解決策 2

理想的には、問題はファイルの内容を安全に返すことです。ファイルの機密性に応じて (たとえば、非公開が優先されるが、そうでない場合は世界の終わりではない)、適切に Web アクセス可能なディレクトリにファイルを "コピー" できますが、名前には UUID を使用します。したがって、Secret1.pdf の場合、cfdirectory を使用してディレクトリを作成し、そのファイルをそのファイルにコピーするとします。次のようなものを提供します。

/files/xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxxxxx/Secret1.pdf を実行し、そのディレクトリにリダイレクトするために a を実行します。

次に、スケジュールされたタスクまたはゲートウェイ、または設定した時間数より古いディレクトリをパージするための任意の方法をセットアップできます。たとえば、ディレクトリ xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxxxxx とそのすべてのファイルを 30 分後に削除します。

于 2013-09-02T01:11:41.517 に答える