Производительность рабочей среды Web.config - лучшие практики

Question

В Visual Studio, когда мы разрабатываем, файл web.config часто изменяется, но я не знаю, что именно изменилось, и каковы последствия в производственной среде для производительности и важны ли разделы конфигурации.

Например:

<compilation>
<compilers>
<runtime>
...

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

Так что мой вопрос:

Что вы ищете в файле web.config в производственной среде, чтобы не снижать производительность и иметь легкий файл конфигурации? Что такое лучшие практики?

Спасибо за ваши ответы!

Answer 1

В Web.Config вы можете настроить, хотите ли вы отлаживать сборки или выпускать сборки.Вы можете настроить производительность WCF, пул потоков.Вы можете настроить ведение журнала и т. Д.

Visual Studio не изменяет для вас критически важные параметры автоматически.Однако единственное, что он делает, - это включает отладочные сборки, когда вы пытаетесь отладить ваше приложение.В этом случае он запрашивает подтверждение.Для производства вы можете отключить отладочные сборки.

Я бы порекомендовал вам использовать инструмент diffmerge, чтобы увидеть, какие разделы добавляются с момента последнего коммита.Однако обратите внимание, что более короткая конфигурация не обязательно означает лучшую производительность.

Ваш web.config объединен с machine.config, который имеет много разделов.Таким образом, отсутствие раздела обычно означает, что вы не изменяете значения по умолчанию в machine.config.Добавление раздела не означает, что вы добавляете что-то новое.Это только означает, что вы настраиваете что-то, что в противном случае будет иметь какую-то настройку по умолчанию.Желательно иметь короткий конфигурационный файл, чтобы сделать его более удобным для обслуживания.Нет смысла снова указывать значения по умолчанию в конфигурации, если они неявно используются по умолчанию или в любом случае находятся в machine.config.VS2010 уже избегает ненужных разделов.

Answer 2

Количество разделов в файле web.config не имеет ничего общего с производительностью.

Для некоторых компьютеров требуется больше настроек, чем для других (и, следовательно, разница в размере), для запуска одного и того же приложения.

Как указал Хасан, файл web.config объединен с файлом конфигурации компьютеров.У вас вполне может быть 1 компьютер (назовите его test), который определяет в своем файле machine.config то, что не определено в вашей рабочей конфигурации.Таким образом, для тестирования вам могут не понадобиться определенные разделы, которые потребуются для производства.

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

Итерация: число разделов не влияет на производительность.С другой стороны, содержимое определенных разделов:

---

Теперь о том, как повысить производительность: это в зависимости от приложения.Для производства вы захотите отключить отладку и включить такие вещи, как сжатие URL для статического содержимого.

Вы могли бы также захотеть включить сжатие для динамического содержимого или даже настроить определенные каталогисообщить браузеру, что содержимое кэшируется (например, / images, / css или javascript).Между прочим, они обычно увеличивают размер вашего рабочего конфигурационного файла и имеют определенные последствия (например, когда вы хотите изменить файл CSS), но, как правило, приводят к повышению производительности для клиента.

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

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