I have custom configuration section within web.config file. I'm lingering between:
Reading it into static class every time when I need any configuration value (because I guess that system already caches files when I open them (for instance when I run Word it takes longer the first time and much less on consecutive opens))
Reading it into static class and caching it using Application.Cache with file dependency and using cached data - I suppose it would be a bit quicker this way, but is it worth the hassle.
What do you think about auto file (on open) caching...
Write a custom configuration section and use ConfigurationManager.GetSection
.NET Takes care of caching this and invalidates whenever the web.config file is changed.
Reading values from web.config is very, very fast. The ConfigurationManager is highly optimized for the purpose. So fast that there is almost no gain over storing the value in Session, Cache, etc. However, if you store a setting in web.config changing the value restarts the app but the old cached value would still be present if you used the Cache ... so don't. Simply read the value from web.config when you need it; on a standard laptop I'm able to read a web.config setting over 600,000 times a second without issue.
AFAIK, config files are already cached in memory as long when the System.Configuration.ConfigurationManager is used.
Just one reason why changing a web.config/app.config requires an app restart to pick up changes
Related
I'm experimenting with enabling the shared cache in a SQLite implementation I'm working on. In the actual app everything works fine, but my unit tests are now failing with "disk I/O error"s. I'm assuming this is because the shared cache is making assumptions about the file that are no longer valid once it's been deleted.
How can I clear out this shared cache data? I've tried running sqlite3_shutdown() followed by sqlite3_initialize() but the problems persist.
I've actually discovered that some of my tests weren't closing connections properly, and that was the source of my problem - shared-cache was just highlighting it (though I'm not 100% sure why).
That said, in my journey, I did manage to find a way to control where SQLite puts its temporary files. the sqlite3_temp_directory global variable lets you define it - by default it's blank and defers to the OS, I think.
If you set that directory you can manually clear out any files whenever you wish.
I am new in Symfony2 and I am working in a project in the prod environment.
I changed a twig file so it looks like I have to clean the cache to update the page.
There is any risk at cleaning the cache of the project?
It is possible that I am going to lost any important file?
If yes, there is a way to make this update of some safer way?
Short answer: yes, it can be dangerous. No, there's no safer way. You should take a backup of the whole application root (cache included).
Details
The cache folder contains "compiled" files. Unless someone is doing something very wrong, it does not contains important files. And - even if it does - it would probably be quite complex to get them out from cache.
So at first glance you should be able to delete the cache anytime you want without fear.
Cache version
There's a small catch: you cannot be sure that - even before your changes - the current cache is sync with the current source code.
If, previously, someone made changes to the application but did not clear the cache, those changes are not actually used in production.
In this case, when you clear the cache all such changes will be released as well as your change.
Suggestion
Right now the only way is forward, so you have to clear the cache. But you may want to:
backup first
get a list of more recent changes to source code
do the task when you have time to test and fix if something comes up
In the long term, you should use a deploy script / system to make sure that the cache is automatically cleared any time some changes to source code is delivered.
I have around 60 web apps on web server, all of these app have some of the same appsetting values in the web.config. These settings are loaded into memory as soon as the application starts. I would like to centralise these values in one config file for all apps to load.
My question is, if i load all of the apps up at the same time, would there be any performance issues accessing this same config file at the same time?
Cheers
Read locks are generally not exclusive so any number of applications can read from the same file at the same time. If you're not specifically requesting read exclusivity, you should be fine.
You should look at how you're loading the configuration file into each application.
See http://en.wikipedia.org/wiki/File_locking for more information.
Probably, because you need disk IO to access the file. But if the values stay in memory, I would say the performance issue would be minimal afterwards. Just be sure to read out the file without locking it (I believe with the FileShare.ReadWrite enum).
You might even see a small performance improvement since the file will be cached by the operation system when the first application reads the file, subsequent files will read directly from memory.
But the only way to know for sure is to measure and see.
I've collected a (hopefully useful) summary of the ways I've researched to accomplish the subject of this post, as well as the problems I have with them. Please tell me if you've found other ways you like better, especially if they resolve the problems that the methods I mention do not.
Leave connection strings in web.config and use XDT/msdeploy transformation to replace them with settings according to my active build configuration (for example, a web.PublicTest.config file). My problem with this is I merge and bury a few server-specific settings into an otherwise globally identical file with many configuration elements. Additionally, I cannot share connection string definitions among multiple peer-level applications.
Specify a configSource="DeveloperLocalConnectionStrings.config" value for connection strings in web.config, and XDT transform this value to point to one of the multiple environment-specific files in my code-base. My problem with this is I send passwords for all my environments to all destinations (in addition to SVN, of course) and have unused config sections sitting on servers waiting to be accidentally used.
Specific connection strings in the machine.config file rather than web.config. Problem: who the heck expects to find connection strings in the machine.config, and the probability of surprise name collisions as a result is high.
Specify a configSource="LocalConnectionStrings.config", do not transform the value, and edit the project xml to exclude deployment of the connection string config. http://msdn.microsoft.com/en-us/library/ee942158.aspx#can_i_exclude_specific_files_or_folders_from_deployment - It's the best solution I've found to address my needs for a proprietary (non-distributed) web application, but I'm paranoid another team member will come one day and copy the production site to test for some reason, and voila! Production database is now being modified during UAT. (Update: I've found I can't use one-click publish in this scenario, only msdeploy command line with the -skip parameter. Excluding a file as above is the same as setting it to "None" compile action instead of "Content", and results in the package deleting it from the deployment target.)
Wire the deployment package up to prompt for a connection string if it isn't already set (I don't know how to do this yet but I understand it is possible). This will have similar results to #4 above.
Specify a configSource="..\ConnectionStrings.config". Would be great for my needs, since I could share the config among the apps I choose, and there would be nothing machine-specific in my application directory. Unfortunately parent paths are not allowed in this attribute (like they are for 'appSettings file=""' - note also that you can spiffily use file= inside a configSource= reference).
p.s. some of these solutions are discussed here: ASP.Net configuration file -> Connection strings for multiple developers and deployment servers
When using SQL Server, you can also use Integrated Security / SSPI and add the WebServer Computer Login to the Sql Server.
That way you dont have to expose anything in the web.config and you can grant roles to that login like you would to any other DB user.
Though you have to understand the implications and security considerations to be taken, because any malicious code executed as THAT machine will have access to the Sql Server.
with regards
Ole
Use the hostname as key for the connectionstring, that way you can choose the datasource automagically. Make sure the choosing routine is not buggy (change hostname - test!)...
Don't put it in the web.config, write an ini file, that way there is no XML encoding.
Encrypt the password therein, with private/public key (RSA/PGP). Don't ever use cleartext, or a symmetric key, which is just as bad.
Check my following blog post: Protecting asp.net machine keys and connection strings
If you do use Quandary's answer, use a key that's not in the site's folder, just like asp.net does with protected config sections.
We manually approve changes to the web.config that go into staging/production. We use integrated instead of username based where possible, but an option we've used in the later case is to just have placeholders for the username/passwords in SVN.
We've used separate config files in the past, but we have run into other type of issues with web.config modifications, so we have been locking it in a single file lately.
Is it possible to update the site dll for a precompiled site without stopping IIS.
Currently, if I try to just copy the new file to overwrite the current file, All users receive runtime errors while the file is being copied. Is there a way to avoid this?
even if you don't stop, any change to the web.config file, BIN folder, App_Data or App_Code will force the .NET compiler to perform ...
and you will loose any Session variables in memory.
What I do is to use Session State in SQL Mode and if your system is set up like this, user will remain in the site (after a longer exposition to a page reload)
.NET will still invoke the compiler in order to compile the new set of instructions but soon it is done, all sessions will be read from SQL Server and because they are still there (and not lost with a memory refresh) users will remain in the website with current credentials.
it is a little bit slower than In-Memory Session State, but much more reliable, specially with Shared hosting :) this is the way to increse/decrese the minutes in your session, as Shared hosting do not allow it to change even if you do
Session.Timeout = 5;
their machine configuration will override everything you do, with SQL Session State, you will be able to set your time as this is all made by SQL Server.
Fell free to read this article to know how everything is done.
Hope it helps.