ConfigurationManager.AppSettings проблемы производительности

голоса
21

Я планирую быть хранить все мои настройки конфигурации в разделе app.config моего приложения ( с использованием ConfigurationManager.AppSettingsкласса). Как пользователь изменяет параметры с помощью пользовательского интерфейса (нажав флажки, выбор радио - кнопки и т.д.), приложение, я планирую писать эти изменения к началам AppSettings. В то же время, в то время как программа работает я планирую получать доступ к AppSettingsпостоянно из процесса , который будет постоянно обработки данных. Изменения параметров через интерфейс должны влиять на обработку данных в реальном времени, поэтому этот процесс будет осуществляться доступ к AppSettingsпостоянно.

Это хорошая идея в отношении производительности? Использование AppSettingsдолжен быть «правильный путь» для сохранения параметров конфигурации и доступа при записи .Net приложений, но я волнуюсь , что этот метод не предназначен для постоянной нагрузки (по крайней мере , с точки зрения настройки постоянно открывающихся чтения).

Если кто имеет опыт работы с этим, я был бы весьма признателен за вход.

Обновление: Я , вероятно , следует уточнить несколько моментов.

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

Согласно справки о MSDN, то ConfigurationManagerдля хранения не только настройки уровня приложений, но пользовательские настройки , а также. (Особенно важно , если, например, приложение устанавливается в качестве частичного доверия приложения.)

Обновление 2: Я принял ответ lomaxx, потому что Propertiesдействительно выглядит как хорошее решение, без добавления каких - либо дополнительных слоев в моем приложении (например, базы данных). При использовании свойств, он уже делает все кэширование , что другие предложили. Это означает , что любые изменения и последующее чтение все сделано в памяти, что делает его очень быстро. Свойства только записывает изменения на диск , когда вы явно указать его в. Это означает , что я могу внести изменения в настройки конфигурации на лету во время выполнения , а затем только сделать окончательный сохранить на диск при выходе из программы.

Просто чтобы убедиться , что будет на самом деле быть в состоянии справиться с нагрузкой , мне нужно, я сделал некоторые испытания на моем ноутбуке , и был в состоянии сделать 750000 читает и 7500 записей в секунду с использованием свойств. То есть до сих пор выше , и за то , что мое заявление будет когда - либо даже приблизиться к необходимости , что я чувствую себя достаточно безопасно в использовании свойств без ущерба для производительности.

Задан 07/08/2008 в 01:12
источник пользователем
На других языках...                            


8 ответов

голоса
8

так как вы используете приложение WinForms, если это в .net 2.0 есть на самом деле система пользовательских настроек ( так называемые свойствами) , который предназначен для этой цели. Эта статья на MSDN имеет очень хорошее введение в этот

Если вы все еще беспокоитесь о производительности , то посмотрите на SQL Compact Edition , который похож на SQLite , но является предложение Microsoft , которое я нашел , играет очень хорошо с WinForms и есть даже возможность заставить его работать с Linq

Ответил 07/08/2008 d 01:45
источник пользователем

голоса
2

AppSettings не на самом деле означает, что вы пытаетесь сделать.

При запуске приложения .NET, он читает в файле app.config, и кэширует его содержимое в памяти. По этой причине, после записи в файл app.config, вам придется каким-то образом заставить среду выполнения повторного анализа файла app.config поэтому она может кэшировать настройки снова. Это ненужное

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

Запрет на использование базы данных, вы можете легко настроить внешний конфигурационный файл XML. При запуске приложения, вы можете кэшировать содержимое в объекте NameValueCollection или HashTable объекта. Как изменить / добавить настройки, вы могли бы сделать это в этой сохраненной копии. Когда приложение завершает работу, или в соответствующем временном интервале, можно записать содержимое кэша обратно в файл.

Ответил 07/08/2008 d 02:10
источник пользователем

голоса
2

Дилан,

Не следует использовать конфигурационный файл приложения для этой цели использовать SQL DB (SQLite, MySQL, MSSQL, что угодно), потому что вы должны будете меньше беспокоиться о проблемах параллелизма во время операций чтения и записи в файл конфигурации.

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

Ответил 07/08/2008 d 01:56
источник пользователем

голоса
2

Проверьте SQLite, похоже, хороший вариант для этого конкретного сценария.

Ответил 07/08/2008 d 01:41
источник пользователем

голоса
1

Я бы не использовать файлы конфигурации для хранения пользовательских данных. Используйте дб.

Ответил 07/08/2008 d 01:43
источник пользователем

голоса
1

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

Ответил 07/08/2008 d 01:26
источник пользователем

голоса
0

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

Кроме того , если возможно, посмотрите на нарушение AppSettings вверх в configSections , так что вы можете прочитать записи и кэш - параметры , связанные.

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

Ответил 07/08/2008 d 01:28
источник пользователем

голоса
0

Могу ли я спросить, почему вы не сохранение настроек пользователя в базе данных?

В общем, я сохранить настройки приложений, которые изменяются очень редко в разделе AppSettings (журналы ошибок по умолчанию; адрес электронной почты отправляются на количество минут, после чего вы автоматически зарегистрированы, и т.д.) Объем этого действительно находится в приложении , а не на пользователя, и, как правило, используется для настройки развертывания.

Ответил 07/08/2008 d 01:27
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more