問題タブ [httpruntime]

.NET 2.0 を実行している Web サイトがあり、ASP.Net HttpRuntime.Cache の使用を開始して、頻繁なデータ ルックアップの結果を保存し、データベース アクセスを削減しました。

スニペット:

キャッシュを見たいときはいつでも悲観的にロックしています。ただし、ロックのオーバーヘッドが発生しないように、代わりにキャッシュ値を確認した後にロックすることを提案するさまざまなブログが Web に投稿されているのを見てきました。チェック後に別のスレッドがキャッシュに書き込んだ可能性があるため、これは正しくないようです。

最後に私の質問は、これを行う「正しい」方法は何ですか? 正しいスレッド同期オブジェクトを使用していますか? ReaderWriterLockSlim() は認識していますが、.NET 2.0 を実行しています。

httpRuntime executionTimeoutASP.NET MVC アプリケーションのサブセクションを増やしたいと考えています。

通常の Web アプリでは、次を使用できます。

ただし、ASP.NET MVC には「フォルダー」という概念は実際にはありません。

ASP.NET MVC パス/Images/Uploadに ImagesController と Upload アクションが含まれているとします。

非常に単純なコード:

そして、私はすでに5分以上出力を待っています。この問題は約 1 週間前 (それよりも前かもしれません) に現れ始め、さらに 3 台のコンピューター (同僚のボックス) で同じ動作が発生しましたが、一部のコンピューターHttpRuntimeは 1 分以内に初期化できましたが、これはまだ非常に奇妙です。

誰もそれを経験しましたか？そして、私はそれで何をしますか？

これが私の問題です。私はヨーロッパの複数の国に展開されているEコマースソリューションに取り組んでいます。アプリケーション内のすべての例外をSQLServerに永続化し、DBに将来DateTimeを持つレコードがあることがわかりました。

web.configでカルチャを定義します（例：pt-PT）。予想される形式はDD-MM-YYYYです。

デバッグ後、DB内のこれらの「将来の」レコードの問題は、使用するコールバックメソッドが原因であることがわかりました。たとえば、キャッシングアーキテクチャでは、コールバックを使用します。

現在のスレッドCultureInfoを確認すると、これらのコールバックでは、pt-PTではなくen-USであり、HttpContextもnullです。コールバックで例外が発生した場合、例外マネージャーはそれをMM-DD-YYYYとして報告するため、SQLServerに誤って保持されます。

残念ながら、例外マネージャーのコードでは、DateTime.Nowを使用しています。これは、コールバックでない場合は問題ありません。他の業種で共有されているため、このコードをカルチャ固有に変更することはできません。

では、なぜASP.Netへのコールバックはコンテキストを維持しないのでしょうか。このコールバックスレッドでそれを維持する方法はありますか？ここでのベストプラクティスは何ですか？

ありがとう。

アプリケーションの起動時にのみインスタンス化する必要があるいくつかのアプリケーション データをキャッシュしようとしています。HttpRuntime.Cache を使用して、サービスの開始時にのみインスタンス化される静的オブジェクトを作成してみました。また、サービス シングルトンを作成してグローバル変数を使用してみました。新しいリクエストがサービスにヒットするたびに、状態が失われます... WCFサービスをWindowsサービスとして作成できると思いますが、ここで何が起こっているのかを知りたいです... IISワーカープロセスが1つだけであることがわかりますスポーンしていますが、毎回サービスをアンロードして再ロードしていると思います。

一部の WCF 構成が欠落しているか、IIS で正しくセットアップされていない可能性がありますか? IIS 内で通常の 2.0 Web サイトとして実行されています。

これは私の最初の投稿です。誰かが私の app.config XML を投稿する方法を教えてくれたら、私はそうします... stackoverflow がそれを HTML として解析しようとしていると思いますが、表示されません。

ありがとうございました！ティム

私は HttpRuntime キャッシュを使用して、社内の [dasboard] asp.net アプリで単純なユーザー設定をキャッシュしています。このアプリは、毎日約 200 人のユーザーが使用しています。

最後のクエリ条件、スケール、オプション (他のチェックボックスに依存するチェックボックスなど) などをキャッシュするだけで、ユーザーがブラウザーを閉じたときに、次回開いたときに正確なダッシュボード/レポート オプションに戻されます。ブラウザ。

これらの値は「無制限」で「動的」であるため、データベースを使用してこれらの値をキャッシュしたくありません。

とにかく、HttpRunime Cahce は正常に動作していますが、運用サーバーでは時々動作しません。この問題を解決する方法はありますか?

AsyncFileUploadコントロールを備えたファイルアップロードページがあります。ユーザーがファイルを参照すると、アップロードコントロールがファイルをメモリにプルします。次に、ファイルをデータベースに保存するために次のコードを起動する[アップロード]ボタンがあります。

ファイルが約500KBを超える場合、コントロールのFileBytesプロパティは単にnullを返すことがわかりました。これは私のサーバーで発生しますが、アプリをローカルで実行すると正常に実行されます。

ファイルをデータベースにコミットする前にユーザーが詳細情報を入力する必要があるため、OnUploadCompletedイベントを処理していません。

これはweb.configにあります：httpRuntime maxRequestLength = "10000" />

私の職場には、次のコードを使用してファイルのダウンロードを実行するASP.NETページがあります。ファイルはzipアーカイブから直接取得されるため、Request.TransmitFile（）ではなくこれを使用します。

httpRuntimeexecutionTimeout設定の妥当な値を決定しようとしています。送信されるファイルのサイズは最大1GBであり、一部のユーザーはWebサーバーへのパイプ^*が非常に遅い（64K回線を考えてください）。これらのユーザーに接続のリセットを経験させたくありません。ただし、サイトの残りの部分については、妥当なタイムアウト値を維持する必要があります。

この特定のページに対してのみexecutionTimeout設定を定義する（またはそのページに対して無制限にする）方法はありますか？推奨されるアプローチは何ですか？ファイルを提供するためにまったく異なる方法（FTPなど）を使用したほうがよいと思いますが、その選択をする自由はありません。私たちにできることは、サイトのコードを変更することだけです。

また、これらのダウンロードは送信する前に圧縮する必要があると思いますが、それは別の問題です。

*トピック外の質問：「遅いパイプ」は厄介な混合比喩ですか？代わりに「小さなパイプ」と言うべきかもしれませんが、この文脈ではそれは私には奇妙に聞こえます。意見？

明確で単純な質問があります。私が取り組んでいる webapplication は、単体テスト (1500 近くのテスト) を使用しています。アプリケーションで必要な変更により、HttpRuntime.BinDirectory に値がなく、ArgumentNullException がスローされるため、いくつかのテストが失敗します。

HttpRuntime.BinDirectory に独自の値を設定する方法はありますか? または、Moq フレームワークを使用してモックしますか?

どんな助けでも大歓迎です！

私たちは最近、私たちのウェブサイトで executionTimeout が機能しなくなったことに気付きました。昨年は間違いなく機能していました...いつ停止したかはわかりません。

私たちは現在実行中です：

• Windows-2008x64
• IIS7
• 32 ビット バイナリ
• マネージド パイプライン モード = クラシック
• フレームワークのバージョン = v2.0

Web.Config は

Timetaken が最大 20 分まで表示される理由についてのヒント。DebugType (full と pdbonly) のコンパイル オプションは効果がありますか?