ASP.NET - основной контрольный список для размещения сайта в производстве

Я создаю статический сайт ASP.NET(используя Masterpages и несколько форм), и я собираюсь выпустить его на мой производственный сервер.

Я знаю об изменении <compilation debug="true"> на false, но мне интересно, что еще я могу сделать, чтобы получить максимально возможную скорость. На сайте нет доступа к данным, все статическое содержимое.

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

Контрольный список до сих пор (не стесняйтесь редактировать это самостоятельно с любыми достойными дополнениями)

  • Убедитесь, что <compilation debug="false" /> на самом деле установлено false в Web.Config
  • Убедитесь, что <trace enabled="false" /> на самом деле установлено false в Web.Config
  • Установить необходимые разрешения на чтение/запись/изменение папки для сайта
  • Включить GZIP в IIS (резко уменьшает размер страниц /css/javascript )
  • Вы рассматривали OutputCaching для любых страниц/элементов управления?
  • Рассмотрите возможность настройки веб-тестов (например, WatiN для .NET), чтобы убедиться, что функции на вашем сайте все еще работают.
  • Удостоверьтесь, что это не в пятницу днем!

ОТВЕТЫ

Ответ 1

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

Ответ 2

Не размещайте в пятницу днем! Это гарантированно испортит вам голову на выходные.

Ответ 3

Кроме того, не забудьте проверить настройки gzip в IIS. Сжатие выходного сигнала будет намного быстрее перемещаться по кабелю.

Ответ 5

Просмотрите свой web.config

Отметьте debug (web.config/*.svc), трассировку,...

Обновить отладочную информацию до производственных значений:

  • адреса электронной почты
  • (веб-сервисные адреса)
  • файлы журнала местоположений

быстрый поиск: ссылка

Ответ 7

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

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

Если вы просто представляете новости и другие мелочи на веб-сайте компании, которые не так часто меняются, то это решение, вероятно, для вас. Даже если его сайт с гигабайтами данных. Ключевым словом является то, как часто мы обновляем данные?

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

Ответ 8

У вас должен быть какой-то тест для проверки различных функций вашего сайта и разрешений. Например, после публикации. Пройдите через контрольный список, могу ли я получить доступ к x, если у меня нет разрешения? Работает ли x, y, z приложение? Я делаю это после каждого опубликования, потому что небольшие изменения могут иметь большое влияние.

Ответ 9

Вы должны прочитать следующее:
https://stackoverflow.com/questions/72394/what-should-a-developer-know-before-building-a-public-web-site

В настоящее время этот 9-й самый высокий голос проголосовал за SO и в списке 3 самых популярных. Предостережение заключается в том, что он не агностик платформы, поэтому он не имеет некоторых элементов, относящихся к ASP.Net.

Ответ 10

Тщательно протестируйте сайт за пределами вашего корпоративного брандмауэра/прокси после очистки кеша браузера. Это поможет обеспечить доступность всех ресурсов (и не на локальном сервере или в кеше). Например, вы можете обнаружить, что используете абсолютные URL-адреса для включения, скажем, файлов JavaScript или CSS. Они отлично работают в среде разработки, но, как только сайт выходит в эфир, они недоступны. Или у вас есть файл CSS в вашем кеше, который впоследствии был удален, но вы не заметили.

Убедитесь, что любые продукты/приложения, которые вы используете, которые имеют ключи, привязанные к домену, будут работать на вашем сайте. Сюда относятся такие вещи, как ключи Google Карты или коммерческие сторонние приложения. Он также включает автоматически создаваемые гиперссылки, отправленные, например, по электронной почте. Вы не хотите, чтобы регистрация пользователя имела ссылку на http://localhost/comfirm.aspx или тому подобное, не могли бы вы?