C# ConfigurationManager.AppSettings 性能问题

ConfigurationManager.AppSettings Performance Concerns

提问by Dylan Bennett

I plan to be storing all my config settings in my application's app.config section (using the ConfigurationManager.AppSettingsclass). As the user changes settings using the app's UI (clicking checkboxes, choosing radio buttons, etc.), I plan to be writing those changes out to the AppSettings. At the same time, while the program is running I plan to be accessing the AppSettingsconstantly from a process that will be constantly processing data. Changes to settings via the UI need to affect the data processing in real-time, which is why the process will be accessing the AppSettingsconstantly.

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

Is this a good idea with regard to performance? Using AppSettingsis supposed to be "the right way" to store and access configuration settings when writing .Net apps, but I worry that this method wasn't intended for a constant load (at least in terms of settings being constantly read).

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

If anyone has experience with this, I would greatly appreciate the input.

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

Update:I should probably clarify a few points.

更新：我可能应该澄清几点。

This is not a web application, so connecting a database to the application might be overkill simply for storing configuration settings. This is a Windows Forms application.

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

According to the MSDN documention, the ConfigurationManageris for storing not just application level settings, but user settings as well. (Especially important if, for instance, the application is installed as a partial-trust application.)

根据 MSDN 文档，ConfigurationManager它不仅用于存储应用程序级别的设置，还用于存储用户设置。（例如，如果应用程序安装为部分信任应用程序，则尤其重要。）

Update 2:I accepted lomaxx's answer because Propertiesdoes indeed look like a good solution, without having to add any additional layers to my application (such as a database). When using Properties, it already does all the caching that others suggested. This means any changes and subsequent reads are all done in memory, making it extremely fast. Properties only writes the changes to disk when you explicitly tell it to. This means I can make changes to the config settings on-the-fly at run time and then only do a final save out to disk when the program exits.

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

Just to verify it would actually be able to handle the load I need, I did some testing on my laptop and was able to do 750,000 reads and 7,500 writes per second using Properties. That is so far above and beyond what my application will evereven come close to needing that I feel quite safe in using Properties without impacting performance.

只是为了验证它实际上能够处理我需要的负载，我在我的笔记本电脑上做了一些测试，并且能够使用 Properties 每秒进行 750,000 次读取和 7,500 次写入。这是迄今为止，超出我的是什么应用程序将永远甚至接近需要，我觉得在使用性能，而不会影响性能相当安全的。

采纳答案by lomaxx

since you're using a winforms app, if it's in .net 2.0 there's actually a user settings system (called Properties) that is designed for this purpose. This article on MSDNhas a pretty good introduction into this

由于您使用的是 winforms 应用程序，如果它在 .net 2.0 中，实际上有一个专为此目的而设计的用户设置系统（称为属性）。MSDN上的这篇文章对此有很好的介绍

If you're still worried about performance then take a look at SQL Compact Editionwhich is similar to SQLite but is the Microsoft offering which I've found plays very nicely with winforms and there's even the ability to make it work with Linq

如果您仍然担心性能，那么看看SQL Compact Edition，它类似于 SQLite，但我发现它是 Microsoft 的产品，它与 winforms 配合得很好，甚至可以使其与 Linq 配合使用

回答by Brandon Wood

Someone correct me if I'm wrong, but I don't think that AppSettings is typically meant to be used for these type of configuration settings. Normally you would only put in settings that remain fairly static (database connection strings, file paths, etc.). If you want to store customizable user settings, it would be better to create a separate preferences file, or ideally store those settings in a database.

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

回答by Shawn

Could I ask why you're not saving the user's settings in a database?

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

Generally, I save application settings that are changed very infrequently in the appSettings section (the default email address error logs are sent to, the number of minutes after which you are automatically logged out, etc.) The scope of this really is at the application, not at the user, and is generally used for deployment settings.

通常，我会在 appSettings 部分保存很少更改的应用程序设置（默认电子邮件地址错误日志发送到，之后您自动注销的分钟数等）这确实是在应用程序中，不是在用户处，通常用于部署设置。

回答by lomaxx

one thing I would look at doing is caching the appsettings on a read, then flushing the settings from the cache on the write which should minimize the amount of actual load the server has to deal with for processing the appSettings.

我会考虑做的一件事是在读取时缓存 appsettings，然后在写入时从缓存中刷新设置，这应该最大限度地减少服务器为处理 appSettings 而必须处理的实际负载量。

Also, if possible, look at breaking the appSettings up into configSectionsso you can read write and cache related settings.

此外，如果可能，请考虑将 appSettings 分解为configSections，以便您可以读取写入和缓存相关设置。

Having said all that, I would seriously consider looking at storing these values in a database as you seem to actually be storing user preferences, and not application settings.

说了这么多，我会认真考虑将这些值存储在数据库中，因为您似乎实际上是在存储用户首选项，而不是应用程序设置。

回答by Shawn

Check out SQLite, it seems like a good option for this particular scenario.

查看 SQLite，对于这种特殊情况，它似乎是一个不错的选择。

回答by Kevin Sheffield

I would not use config files for storing user data. Use a db.

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

回答by Kev

Dylan,

迪伦，

Don't use the application config file for this purpose, use a SQL DB (SQLite, MySQL, MSSQL, whatever) because you'll have to worry less about concurrency issues during reads and writes to the config file.

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

You'll also have better flexibility in the type of data you want to store. The appSettings section is just a key/value list which you may outgrow as time passes and as the app matures. You could use custom config sections but then you're into a new problem area when it comes to the design.

您还将在要存储的数据类型方面拥有更好的灵活性。appSettings 部分只是一个键/值列表，您可能会随着时间的推移和应用程序的成熟而不再增长。您可以使用自定义配置部分，但是当涉及到设计时，您就会进入一个新的问题领域。

回答by Seibar

The appSettings isn't really meant for what you are trying to do.

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

When your .NET application starts, it reads in the app.config file, and caches its contents in memory. For that reason, after you write to the app.config file, you'll have to somehow force the runtime to re-parse the app.config file so it can cache the settings again. This is unnecessary

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

The best approachwould be to use a database to store your configuration settings.

在最好的办法是使用一个数据库来存储配置设置。

Barring the use of a database, you could easily setup an external XML configuration file. When your application starts, you could cache its contents in a NameValueCollection object or HashTable object. As you change/add settings, you would do it to that cached copy. When your application shuts down, or at an appropriate time interval, you can write the cache contents back out to file.

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