1

У меня проблемы с производительностью здесь: приведенный ниже код является частью моего пользовательского VirtualPathProvider, я перезаписал GetCacheKey и GetCacheDependency, чтобы они могли кэшировать мои просмотры бритвы должным образом.Как я могу поместить журнал, когда компилятор перекомпилирует мой вид бритвы через VirtualPathProvider?

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 веб-сайтов, он принимает возрастов получить страницы, сделанные.

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

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

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

Заранее благодарен.

+0

У вас есть '' установлен в вашем web.config? Если я правильно помню, кеширование отключено по умолчанию, если ваш web.config отключен отладки, даже если он скомпилирован в режиме деблокирования. –

+0

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

ответ

0

Привет для тех, кто заинтересован, чтобы узнать исход этого вопроса:

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

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

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

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

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

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

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

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

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

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

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

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