1

ここで少しパフォーマンスの問題があります。以下のコードはカスタム VirtualPathProvider の一部です。GetCacheKey と GetCacheDependency を上書きして、剃刀ビューを適切にキャッシュできるようにしました。

public override string GetCacheKey(string virtualPath)
{
    var key = string.Empty;
    var fileResult = VerifyFilePath(virtualPath);
    if (fileResult.RefinedAccessPath.IsNotNullOrEmpty())
        key = EncryptHelper.MD5Encrypt(fileResult.RefinedAccessPath);
    else
        key = EncryptHelper.MD5Encrypt(fileResult.VirtualPath);

    return key;
}

public override string GetFileHash(string virtualPath, System.Collections.IEnumerable virtualPathDependencies)
{
    var fileResult = VerifyFilePath(virtualPath);
    var hash = string.Empty;
    if (fileResult.RefinedAccessPath.IsNotNullOrEmpty())
        hash = EncryptHelper.MD5Encrypt(fileResult.RefinedAccessPath);
    else
        hash = Previous.GetFileHash(fileResult.VirtualPath, virtualPathDependencies);

    return hash;

}
public override System.Web.Caching.CacheDependency GetCacheDependency(string virtualPath, System.Collections.IEnumerable virtualPathDependencies, DateTime utcStart)
{
    var fileResult = VerifyFilePath(virtualPath);
    switch (fileResult.Result)
    {
        case ExistenceResult.FoundInCloudAfterRebuildPath:
        case ExistenceResult.FoundInCloudDirectly:
            return new OSiteCacheDependency(fileResult.LastModified, ositeVirtualPathHelper.SiteID.ToString(), utcStart);
        default:
            if (fileResult.RefinedAccessPath.IsNotNullOrEmpty())
                return new System.Web.Caching.CacheDependency(fileResult.RefinedAccessPath);
            else
                return null;
    }
}

ただし、現在、コードが正しいかどうか少し心配です。ローカル PC でテストすると完全に動作しますが、Azure Web サイトにアップロードすると、ページがレンダリングされるまでに AGES かかります。

ビューは Azure Blob ストレージに保存され、GetFile にログ エントリを配置すると、それらがキャッシュされていることがわかりますが、Web サイトは各ページで常に再コンパイルされているように見えます (はい、各ページです。リフレッシュするとコンパイルされるためです)。 Azure Web サイト ページはすぐに表示されますが、アクセスしたことのない他のページは表示されません)

したがって、私の最初の推測では、Azure Web サイトのパフォーマンスは非常に低いですが、それを P3 Large Instance Web App Service プランにアップグレードしても、同じ問題が発生しました。それで、VirtualPathProvider にもう一度エラーがあるのではないかと考えました。GetFile() メソッドが常にヒットするとは限らず、アクセスしたページが更新直後に表示されるため、キャッシュも機能していると確信しているため、プロセス中に他のコンパイルが発生して各ページが非常に多く使用されているかどうかを考えさせられます最初のロードの時間？

誰か助けてください...

前もって感謝します。

4

1 に答える 1

0

この問題の結果を知りたい方へこんにちは:

完璧な解決策は見つかりませんでしたが、Web サイトをクラウド サービスにデプロイした後、すぐに問題が解決したことがわかりました。

コード、デプロイ、またはビューに違いはありませんが、Azure Web サイトとクラウド サービスを比較する専用リソースに問題があると思います (Large instance Azure Web サイトを試したにもかかわらず、標準と競合しませんでした)何らかの理由で中規模のクラウド サービス インスタンス。)

何百万人もの人々が Azure を使用していると確信しているため、私のコードに重大なパフォーマンスの問題があることは間違いありません。最初に Cloud Service を使用して機能させる必要があり、次に展開後に最適化する方法を見つけようとします (そうしないと、クライアントに怒られてしまいます!)

どうしたの：

複雑さ 1)私たちのアプリケーションは、実際にはマルチテナントの ASP.NET MVC Web サイトであり、顧客のために Web サイトをレンダリングします (つまり、Web サイト ビルダー)。お客様が Razor Views に独自のコードを持つことを許可しているため、コンパイル時のパフォーマンスへの影響が犠牲になります (したがって、このトピックの問題です)。

複雑さ 2)すべてのクライアントの Web サイトはまったく異なり、ビューは Azure Blob Storage に保存されます。(これらの Web サイトを管理するための別のバックエンド システムがあります) したがって、ビューにローカル ファイル システムを使用することはできません。つまり、既定の ASP.NET MVC ビュー エンジンは機能せず、基本的なカスタム ビュー エンジンを実行すると、どちらも機能しないため、独自の VirutalPathProvider と CacheDependency を実装することになりました

複雑さ 3)当社の Web サイトは独自の内部 OAuth サーバーを使用して管理されているため、基本的に Web サイトで取得されるすべてのデータは内部 API 呼び出しを介して行われるため、ビューのレンダリング時間も遅延します。

私たちは過去数週間、複雑さを解決するために週末と夜に取り組んできました 2)。

文字通り、真夜中の午前 2 時に一緒に座って、何がうまくいかなかったのかを考え、基本的な重要な要因を上記のようにしました。複雑さ 3) には確実に取り組みますが、複雑さ 1) については、問題を解決するために一時的にクラウド サービスを選択する必要があります (それでも遅いですが、少なくとも Web サイトは許容できる時間内に開くことができます)。

独自の専用サーバー、VPS、さらには Azure VM を使用したときにもフラストレーションが発生しました (プラットフォームでレンダリングされた Web サイトは、ローカル デバッグ モードで 2 秒以内に開くことができ、Azure SQL と Blob Storage へのリモート接続については言及されていません)。 )

そのため、神話はまだ残っており、根本的な解決策はまだ見つかっていません。しかし、当面は現在の速度と現在のクラウド サービスで作業し、後でお客様が落ち着いたらさらに調査を行うという決定が下されました...

上記の私の文章に基づいて、私たちが間違ったことをしたか、何か手がかりを持っているか、気づいている人は、私に知らせてください-非常に感謝しています!

于 2015-12-13T11:33:51.193 に答える