1

質問にコンテキストを与えるために、Application_BeginRequest で呼び出されるプロファイラーを作成しましたが、すべて (JavaScript、画像など) をログに記録しています。最後の手段としてプロファイラー クライアントにフィルタリングを追加することもできますが、リクエストにルーティングが必要であると判断できる場合にのみ、プロファイラーをアクティブにすることをお勧めします。理想的には Application_BeginRequest にありますが、ルーティングのための着信要求の冗長処理なしでは不可能だと思います...

つまり、リクエストが静的リソースに対するものかどうかを判断できるリクエスト ライフ サイクルの最も早い時点はいつで、どのように対処しますか?

System.Web.Routing.RouteTable から派生またはフックして、そこからプロファイラー コードを呼び出すことは可能でしょうか?

4

3 に答える 3

2

さまざまなオプションがあります。最初に - Request.PhysicalPath を使用して静的ファイルを特定するには - チェックアウト: Check for a static file during Application_BeginRequest?

1 つの代替手段は、これをハンドラーとして使用し、パスを使用して、たとえば web.config に含めるファイルの種類 (*.aspx) を記録することです。その後、かなり早い段階でイベントにアクセスできます (asp.net パイプラインを参照)。

または、 httpmodule を使用するだけです-すべてをチェックし、言及したように非物理的なアイテムのみをプロファイルします。

または-最初のリンクで現在のメソッドを使用して、単に Request.PhysicalPath を確認し、それがうまくいくことを願っています:)

于 2011-07-26T04:06:57.957 に答える
2

MVC フィルターを使用すると前処理と後処理の動作を追加でき、filterContextパラメーターで十分な情報が得られる ため、プロファイリングには MVCフィルターを使用することをお勧めします。

たとえば、プロファイリング用に ProfilerAttribute を作成します 

public class ProfilerAttribute : FilterAttribute, IActionFilter, IResultFilter, IExceptionFilter {
    public void OnActionExecuting(ActionExecutingContext filterContext) {
        Debug.WriteLine("Before Action is executing");
    }

    public void OnActionExecuted(ActionExecutedContext filterContext) {
        Debug.WriteLine("After Action is executed");
    }

    public void OnResultExecuted(ResultExecutedContext filterContext) {
        Debug.WriteLine("After Action Result is executed");            
    }

    public void OnResultExecuting(ResultExecutingContext filterContext) {
        Debug.WriteLine("Before Action Result is executing");
    }

    public void OnException(ExceptionContext filterContext) {
        Debug.WriteLine("oops! exception");
    }
}

Global.ascxにGlobalFilterとして登録します....

public static void RegisterGlobalFilters(GlobalFilterCollection filters) {
    filters.Add(new HandleErrorAttribute());
    filters.Add(new ProfilerAttribute());
}

それが役立つことを願っています。ありがとう。

更新: MVC フィルターは、ルーティングが一致した後にのみ実行されることを忘れていました。したがって、MVC によって既に行われているため、静的リソースを除外する必要はありません。

于 2011-07-26T07:02:16.303 に答える
1

別の角度からアプローチしてみましたが、結果には非常に満足しています。基本的に、まったく「ルーティング」できないのに、静的リソース要求を検出するのはなぜですか? global.asax で:

private readonly string[] STATIC_CONTENT_PATHS = new string[] { "css", "js", "img" }; 

public static void RegisterRoutes(RouteCollection routes)
{    
    foreach (string path in STATIC_CONTENT_PATHS) { routes.IgnoreRoute(path + @"/{*foo}"); }

    // other MapRoute calls here
}

静的リクエストをチェックする必要がなくなりましたが、何らかの理由でチェックしたい場合は、次のことを行うことができます。

protected void Application_BeginRequest()
{            
    if (IsStaticRequest())
    {
         // do something here
    }
}

private bool IsStaticRequest()
{
   var result = Request.Url.AbsolutePath.Split('/');
   if (result.Length < 2) return false;
   return STATIC_CONTENT_PATHS.Contains(result[1]);
}

静的コンテンツを提供する唯一のパスが何であるかを絶対に確実に知っているので、これはかなり堅牢なソリューションのように思えます。私はまだ他のアイデアを受け入れていますが、これは私のニーズによく合っていると思います.

于 2011-07-26T05:25:25.923 に答える