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

Question

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

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

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

Дилан,

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

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

Answer 4

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

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

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

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

Answer 5

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

Answer 6

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

Answer 7

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

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

Answer 8

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

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

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