I am loading an XML file in my local server (not a remote server) using:
XDocument.Load(path_to_xml_file);
This file is 500KB. I am wondering if I should cache the XDocument instead of reading the file every time. Thank you for the guidance.
Depends on how often you are going to need it. Consider that apart from the loading time there is also a parsing time which occurs every time you load it from disk.
If your file is not willing to change very often you can put your XDocument in the cache, and defining a file dependency on the file itself, so that the cache is invalidated everytime your document changes. There is an example for this in MSDN
Related
I'm building a website (for personal use, low load) and instead of using an Access or MySQL database for data storage I'm thinking of having one XML file that I load and parse on Application_Start and then keep in memory (in static objects). The website then do reads and writes against these in-memory objects and I will finally persist all data to the XML file on Application_Disposed.
I'm aware that I'll need to make reading/writing thread-safe, but besides that, does anyone see any problem using this approach?
Yes, I see a big problem: There are a number of reasons to why the whole application might die without you knowing about it, and without your data being saved to that xml file.
You'll find Application_Dispose can get fired multiple times (so might don't be the best place to dispose your DI containers etc) whereas Application_End will only fires once (you can prove this by adding logging)
https://bytes.com/topic/asp-net/answers/561768-event-sequence
https://learn.microsoft.com/en-us/previous-versions/ms178473(v=vs.140)?redirectedfrom=MSDN
It seems VS2019 IIS Express doesn't seem to call Application_End as it should when you stop debugging, But IIS will.
I have a .jpg file which represents the current image from a webcam. User's will be downloading this file at an interval of once a second. Because there could be dozens of users reading it, this could be dozens of times a second (which is normal for any web server).
Problem is, this image is updated by a 3rd party application also once a second which "spiders" my local networks webcam portal image. This is so we can build our webcams into our current administration panel.
The problem I am already finding is ASP.net sometimes gets an error it can not access the file because it is open for write permissions by the bot. Likewise, the bot can not access it because IIS is feeding it to the user.
The bot uses io.streamwriter to save the data to the file, and my script uses Response.WriteFile to send the file to the script. (I need to use an actual ASP.net page with a JPG content-type that feeds the file to make sure only users with a active session can view the JPG).
My question is what is the best practices for this? I know why it's happening but what is the best resolution for this? Would storing as a BLOB in a database maybe be smarter since databases are created for concurrent read/writing already? Is there an easier way of doing this with a file I have not thought of yet?
Thanks in advance,
Anthony Greco
Using a BLOB will work if the readers use SNAPSHOT isolation model (SQL Server 2005 and up). See Download and Upload images from SQL Server via ASP.Net MVC for how to stream an image from a BLOB, and see Understanding Row Versioning-Based Isolation Levels for a lecture on SNAPSHOT.
But using a BLOB may be overkill, you could get away with something much simpler. For instance, if you only have one ASP.Net process, then you could have a global volatile variable for the current file name. The writer writes the JPG into a new file, and then updates the global 'current' file name with an Interlocked.CompareExchange operation (it has to be Compare because a newer writer might actually finish faster, outrun a previous writer, and you want to preserve the latest update). There are still some issues left to solve (find out the file name at startup, clean up old files etc) but they are all fairly ease to solve.
If you have a farm of servers, or multiple ASP.Net processes serving the site, then things could get complicated. I would still do a rotating file name and do a try-and-error approach (try to respond with newest file, fall back to previous older one if conflict is detected).
You could get the bot to write the data to a different filename and then do a delete and rename to the filename being served by ASP.Net. This should reduce the file lock time down to the time for a delete and rename to occur. To clarify:
ASP.Net serving image from "webcam.jpg"
bot writes image data to "temp.jpg"
when last image byte written, bot deletes "webcam.jpg" and renames "temp.jpg" to "webcam.jpg"
ASP.Net should check "webcam.jpg" exists, if not wait 10ms (or suitable small increment) and check again.
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 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
I have made a upload page to upload dll to server, many of the times the dll gets corrupt on upload.
How do I detect that the file uploaded is corrupt or not in asp.net?
There's no way to detect a corruption without something else as a reference (eg, MD5 sum). Any file can contain any data, so simply inspecting a file without any semantics at all won't tell you anything.
Is it only dll files that get corrupted? Not sure why this would be the case, but zipping them might help? You would need to create some kind of late binding test method or something to test the dll.