Как я могу поместить журнал всякий раз, когда компилятор перекомпилирует мое представление бритвы через VirtualPathProvider?

Question

У меня возникла небольшая проблема с производительностью: приведенный ниже код является частью моего пользовательского 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;
    }
}

Однако в настоящее время меня немного беспокоит, верен ли мой код или нет - потому что, когда я тестирую его на своем локальном ПК, он работает отлично, однако, если я загружаю его на веб-сайты Azure, требуется AGES, чтобы отобразить страницы.

Представления хранятся в хранилище BLOB-объектов Azure, и я помещаю записи журнала в GetFile и обнаруживаю, что они кэшируются, однако похоже, что веб-сайт постоянно перекомпилируется на каждой странице (да, на каждой странице, потому что, когда он компилируется, если я обновляю на странице веб-сайта Azure она отображается мгновенно, но не на других страницах, которые я не посещал)

Итак, мое первое предположение - производительность веб-сайта Azure очень низкая, однако затем я обновил его до плана обслуживания веб-приложений для крупных экземпляров P3 и получил еще одну проблему. Так что это заставило меня задуматься, есть ли у меня какая-либо ошибка в VirtualPathProvider снова? Поскольку метод GetFile() не всегда срабатывает, а посещенная страница отображается сразу после обновления, я уверен, что кеширование также работает, поэтому я не думаю, что в процессе происходит какая-либо другая компиляция, которая заставляет каждую страницу занимать так много времени. время для первой загрузки?

Может кто-нибудь помочь, пожалуйста...

Заранее спасибо.

Answer 1

Привет тем, кому интересно узнать результат этого выпуска:

ну, я не нашел идеального решения, однако я обнаружил, что после развертывания веб-сайта на облачной службе проблема была решена практически сразу...

Там нет никакой разницы в коде, в развертывании или что-то в представлениях, но я думаю, что есть проблема на выделенных ресурсах, сравнивая веб-сайты Azure с облачной службой (даже при том, что я пробовал веб-сайт Azure Large instance, он не конкурировал со стандартным по какой-то причине экземпляр облачного сервиса среднего размера.)

Я уверен, что миллионы пользователей используют Azure, поэтому нет сомнений в том, что в моем коде есть критические проблемы с производительностью. Сначала я должен заставить его работать, используя Cloud Service, а затем попытаться найти способ оптимизировать его после развертывания (в противном случае наши клиенты сведут нас с ума!)

Так что же случилось:

Сложность 1) Наше приложение на самом деле является мультитенантным веб-сайтом ASP.NET MVC, который отображает веб-сайты для наших клиентов (т.е. создатель веб-сайтов). Мы даем клиентам возможность иметь собственный код в Razor Views, что снижает производительность при компиляции (отсюда наша проблема в теме).

Сложность 2) Веб-сайты всех наших клиентов совершенно разные, и их представления хранятся в хранилище BLOB-объектов Azure! (У нас есть другая отдельная серверная система для управления этими веб-сайтами.) Поэтому мы не можем использовать локальную файловую систему для представлений - то есть ASP.NET MVC View Engine по умолчанию не будет работать, и при использовании основного настраиваемого обработчика представлений не работают, что приводит нас к реализации наших собственных VirutalPathProvider и CacheDependency

Сложность 3) Наш веб-сайт управляется с помощью нашего собственного внутреннего сервера OAuth, поэтому в основном все данные, получаемые с веб-сайта, поступают через внутренние вызовы API, что также задерживает время отображения представления.

В последние несколько недель мы работали по выходным и ночам, решая сложность 2), и сейчас крайне расстроены низкой производительностью.

Буквально мы сидим вместе в 2 часа ночи и думаем о том, что пошло не так и сделали основные ключевые факторы, как указано выше. Мы будем решать Сложность 3) наверняка, но для Сложности 1) мы должны временно выбрать Cloud Service для решения проблемы (все еще медленно, но по крайней мере веб-сайты могут быть открыты в приемлемое время)

Разочарование также пришло, когда мы используем наш собственный выделенный сервер, VPS и даже виртуальную машину Azure, все работало без проблем (веб-сайты, представленные на платформе, можно открыть в режиме локальной отладки в течение 2 секунд, не говоря уже об удаленном подключении к Azure SQL и хранилищу BLOB-объектов.)

Так что мифы все еще существуют, окончательное решение еще не найдено. Но было принято решение, что мы будем работать с текущей скоростью и текущим облачным сервисом, а затем проведем дальнейшее расследование, когда сначала уладим своих клиентов...

Любой, кто имеет какое-либо представление или осознает, что мы сделали неправильно, основываясь на моих статьях выше, пожалуйста, дайте мне знать - высоко ценится!