Проблемы с производительностью ConfigurationManager.AppSettings
Я планирую хранить все свои настройки конфигурации в разделе приложения app.config (используя класс ConfigurationManager.AppSettings). Поскольку пользователь изменяет настройки с помощью пользовательского интерфейса приложения (устанавливая флажки, выбирая переключатели и т. д.), Я планирую записывать эти изменения в AppSettings. В то же время, пока программа работает, я планирую постоянно получать доступ к AppSettings из процесса, который будет постоянно обрабатывать данные. Изменения настроек через пользовательский интерфейс должны влиять на обработку данных в режиме реального времени, поэтому процесс будет получать доступ к AppSettings постоянно.
Это хорошая идея с точки зрения производительности? Предполагается, что использование AppSettings является «правильным способом» для хранения и доступа к настройкам конфигурации при написании приложений .Net, но я беспокоюсь, что этот метод не был предназначен для постоянной загрузки (по крайней мере, с точки зрения постоянно считываемых настроек).
Если у кого-то есть опыт в этом, я был бы очень признателен за ваш вклад.
Обновлять: Мне, наверное, следует прояснить несколько моментов.
Это не веб-приложение, поэтому подключение базы данных к приложению может оказаться излишним просто для хранения параметров конфигурации. Это приложение Windows Forms.
Согласно документации MSDN, ConfigurationManager предназначен для хранения не только настроек уровня приложения, но и настроек пользователя. (Это особенно важно, если, например, приложение установлено как приложение с частичным доверием.)
Обновление 2: Я принял ответ lomaxx, потому что Properties действительно выглядит как хорошее решение, без необходимости добавлять какие-либо дополнительные слои в мое приложение (например, базу данных). При использовании свойств он уже выполняет все кеширование, которое предлагали другие. Это означает, что все изменения и последующие чтения выполняются в памяти, что делает его чрезвычайно быстрым. Свойства записывают изменения на диск только тогда, когда вы явно укажете это. Это означает, что я могу вносить изменения в настройки конфигурации на лету во время выполнения, а затем делать окончательное сохранение на диск только после выхода из программы.
Чтобы убедиться, что он действительно сможет справиться с нужной мне нагрузкой, я провел небольшое тестирование на своем ноутбуке и смог выполнить 750 000 операций чтения и 7 500 операций записи в секунду с помощью свойств. Это намного больше, чем то, что мое приложение будет Когда-либо даже близко к необходимости, что я чувствую себя в полной безопасности при использовании свойств, не влияя на производительность.
Ответы 8
Кто-то поправит меня, если я ошибаюсь, но я не думаю, что AppSettings обычно предназначен для использования для такого типа настроек конфигурации. Обычно вы устанавливаете только те параметры, которые остаются довольно статичными (строки подключения к базе данных, пути к файлам и т. д.). Если вы хотите сохранить настраиваемые пользовательские настройки, было бы лучше создать отдельный файл настроек или, в идеале, сохранить эти настройки в базе данных.
Могу я спросить, почему вы не сохраняете пользовательские настройки в базе данных?
Как правило, я сохраняю настройки приложения, которые меняются очень редко в разделе appSettings (отправляются журналы ошибок адреса электронной почты по умолчанию, количество минут, после которых вы автоматически выходите из системы и т. д.). , а не у пользователя, и обычно используется для настроек развертывания.
одна вещь, которую я хотел бы сделать, - это кэшировать настройки приложения при чтении, а затем сбрасывать настройки из кеша при записи, что должно минимизировать количество фактической нагрузки, с которой сервер должен иметь дело для обработки appSettings.
Кроме того, если возможно, попробуйте разбить appSettings на configSections, чтобы вы могли читать настройки, связанные с записью и кешированием.
Сказав все это, я бы серьезно подумал о том, чтобы сохранить эти значения в базе данных, поскольку вы, похоже, на самом деле храните предпочтения пользователей, а не настройки приложения.
Проверьте SQLite, он кажется хорошим вариантом для этого конкретного сценария.
Я бы не стал использовать файлы конфигурации для хранения пользовательских данных. Используйте db.
поскольку вы используете приложение winforms, если оно в .net 2.0, на самом деле существует система пользовательских настроек (называемая «Свойства»), которая предназначена для этой цели. Эта статья в MSDN дает довольно хорошее введение в это
Если вы все еще беспокоитесь о производительности, взгляните на SQL Compact Edition, который похож на SQLite, но является предложением Microsoft, которое, как я обнаружил, очень хорошо работает с winforms, и есть даже возможность заставить его работать с Linq
Дилан,
Не используйте файл конфигурации приложения для этой цели, используйте базу данных SQL (SQLite, MySQL, MSSQL, что угодно), потому что вам придется меньше беспокоиться о проблемах параллелизма во время чтения и записи в файл конфигурации.
У вас также будет большая гибкость в выборе типа данных, которые вы хотите хранить. Раздел appSettings - это просто список ключей / значений, который вы можете перерасти с течением времени и по мере развития приложения. Вы можете использовать настраиваемые разделы конфигурации, но тогда вы попадаете в новую проблемную область, когда дело доходит до дизайна.
AppSettings на самом деле не предназначен для того, что вы пытаетесь сделать.
Когда ваше приложение .NET запускается, оно читает файл app.config и кэширует его содержимое в памяти. По этой причине после записи в файл app.config вам придется каким-то образом заставить среду выполнения повторно проанализировать файл app.config, чтобы она могла снова кэшировать настройки. Это не нужно
лучший подход будет использовать базу данных для хранения ваших настроек конфигурации.
Запрещая использование базы данных, вы можете легко настроить внешний файл конфигурации XML. Когда ваше приложение запускается, вы можете кэшировать его содержимое в объекте NameValueCollection или HashTable. Когда вы изменяете / добавляете настройки, вы будете делать это с этой кэшированной копией. Когда ваше приложение завершает работу или через соответствующий промежуток времени, вы можете записать содержимое кэша обратно в файл.