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

Question

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

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

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

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

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

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

16

asp.net performance deployment production

Источник

user1692 25 ноя '08 в 21:51

10 ответов

Другие вопросы по тегам asp.net performance deployment production

user31444 01 дек '08 в 02:59 2008-12-01 02:59 · Answer 1 · 2008-12-01 02:59

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

7

Источник

user31444 01 дек '08 в 02:59

user71 25 ноя '08 в 22:04 2008-11-25 22:04 · Answer 2 · 2008-11-25 22:04

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

7

Источник

user71 25 ноя '08 в 22:04

user1685 25 ноя '08 в 21:58 2008-11-25 21:58 · Answer 3 · 2008-11-25 21:58

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

3

Источник

user1685 25 ноя '08 в 21:58

user60045 05 июн '09 в 12:51 2009-06-05 12:51 · Answer 4 · 2009-06-05 12:51

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

3

Источник

user60045 05 июн '09 в 12:51

user23805 25 ноя '08 в 21:53 2008-11-25 21:53 · Answer 5 · 2008-11-25 21:53

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

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

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

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

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

2

Источник

user23805 25 ноя '08 в 21:53

user19307 25 ноя '08 в 22:28 2008-11-25 22:28 · Answer 6 · 2008-11-25 22:28

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

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

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

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

user4435 25 ноя '08 в 22:01 2008-11-25 22:01 · Answer 7 · 2008-11-25 22:01

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

2

Источник

user4435 25 ноя '08 в 22:01

user33371 26 мар '09 в 13:03 2009-03-26 13:03 · Answer 8 · 2009-03-26 13:03

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

user3043 07 сен '09 в 16:20 2009-09-07 16:20 · Answer 9 · 2009-09-07 16:20

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

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

user140392 07 сен '09 в 16:41 2009-09-07 16:41 · Answer 10 · 2009-09-07 16:41

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

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