ConfigurationManager.AppSettings 性能问题

我计划将所有配置设置存储在应用程序的 app.config 部分(使用 ConfigurationManager.AppSettings 类)。当用户使用应用程序的 UI(单击复选框、选择单选按钮等)更改设置时,我计划将这些更改写入 AppSettings。同时,在程序运行时,我计划从一个不断处理数据的进程中不断访问 AppSettings。通过 UI 更改设置需要实时影响数据处理,这就是进程将不断访问 AppSettings 的原因。

就性能而言,这是一个好主意吗?在编写 .Net 应用程序时,使用 AppSettings 应该是存储和访问配置设置的“正确方法”,但我担心这种方法不适用于恒定负载(至少在正在不断读取设置)。

如果有人有这方面的经验,我将不胜感激。

更新:我应该澄清几点。

这不是一个 Web 应用程序,因此将数据库连接到应用程序可能只是为了存储配置设置而过大。这是一个 Windows 窗体应用程序。

根据 MSDN 文档,ConfigurationManager 不仅用于存储应用程序级设置,还用于存储用户设置。 (例如,如果应用程序安装为部分信任应用程序,则尤为重要。)

更新 2: 我接受了 lomaxx 的回答,因为 Properties 确实看起来是一个不错的解决方案,无需向我的应用程序添加任何附加层(例如数据库) .使用 Properties 时,它已经完成了其他人建议的所有缓存。这意味着任何更改和后续读取都在内存中完成,因此速度非常快。属性仅在您明确告诉它时将更改写入磁盘。这意味着我可以在运行时即时更改配置设置,然后仅在程序退出时才将最终保存到磁盘。

为了验证它实际上是否能够处理我需要的负载,我在我的笔记本电脑上做了一些测试,并且能够使用 Properties 每秒进行 750,000 次读取和 7,500 次写入。这远远超出了我的应用程序永远所需要的,我觉得在不影响性能的情况下使用 Properties 非常安全。

请先 登录 后评论

6 个回答

Kevin Sheffield

我不会使用配置文件来存储用户数据。使用数据库。

请先 登录 后评论
Shawn

请问您为什么不将用户的设置保存在数据库中?

通常,我在 appSettings 部分保存很少更改的应用程序设置(默认电子邮件地址错误日志发送到,之后您自动注销的分钟数等)。在应用程序,而不是用户,通常用于部署设置。

请先 登录 后评论
Kev

迪伦

不要将应用程序配置文件用于此目的,而应使用 SQL DB(SQLite、MySQL、MSSQL 等),因为在读取和写入配置文件期间,您不必担心并发问题。

您还可以更灵活地选择要存储的数据类型。 appSettings 部分只是一个键/值列表,随着时间的推移和应用程序的成熟,您可能会超出它的范围。您可以使用自定义配置部分,但随后在设计方面遇到了新的问题。

请先 登录 后评论
Shawn

查看 SQLite,对于这种特定场景,它似乎是一个不错的选择。

请先 登录 后评论
Seibar

appSettings 并非真正适用于您要执行的操作。

当您的 .NET 应用程序启动时,它会读入 app.config 文件,并将其内容缓存在内存中。因此,在写入 app.config 文件后,您必须以某种方式强制运行时重新解析 app.config 文件,以便它可以再次缓存设置。这是不必要的

最佳方法是使用数据库来存储您的配置设置。

除非使用数据库,否则您可以轻松设置外部 XML 配置文件。当您的应用程序启动时,您可以将其内容缓存在 NameValueCollection 对象或 HashTable 对象中。当您更改/添加设置时,您将对缓存的副本执行此操作。当您的应用程序关闭时,或在适当的时间间隔内,您可以将缓存内容写回文件。

请先 登录 后评论
Brandon Wood

如果我错了,有人会纠正我,但我不认为 AppSettings 通常用于这些类型的配置设置。通常,您只会放入保持相当静态的设置(数据库连接字符串、文件路径等)。如果您想存储可自定义的用户设置,最好创建一个单独的首选项文件,或者最好将这些设置存储在数据库中。

请先 登录 后评论