ASP.NET - базовый контрольный список для запуска сайта в производство - PullRequest
Новая
       57

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

14 голосов
/ 26 ноября 2008

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

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

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

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

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

Ответы [ 10 ]

7 голосов
/ 26 ноября 2008

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

6 голосов
/ 01 декабря 2008

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

3 голосов
/ 05 июня 2009
3 голосов
/ 26 ноября 2008

Также не забудьте проверить настройки gzip в IIS. Сжатие выходного сигнала значительно ускорит движение по проводам.

2 голосов
/ 26 ноября 2008

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

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

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

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

2 голосов
/ 26 ноября 2008

Если все статическое содержимое, вы захотите использовать агрессивное Кэширование вывода

2 голосов
/ 26 ноября 2008

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

Проверка отладки (web.config / * .svc), трассировка, ...

Обновление отладки до производственных значений:

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

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

1 голос
/ 26 марта 2009

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

0 голосов
/ 07 сентября 2009

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

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

0 голосов
/ 07 сентября 2009

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

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

...