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

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

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

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

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

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

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

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

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

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

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

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

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

Ваш web.config объединен с machine.config, в котором много разделов. Поэтому отсутствие раздела обычно означает, что вы не изменяете значения по умолчанию в machine.config. Добавление раздела не означает, что вы добавляете что-то новое. Это только означает, что вы настраиваете что-то, что в противном случае будет иметь некоторые настройки по умолчанию.

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