Last post Jun 15, 2012 04:26 PM by Sparkers
Jun 15, 2012 10:44 AM|MattsDotNetUsername|LINK
I have an internal website that is used to import fairly large data files. It was written offshore and pretty buggy and very slow. I am working on refactoring to get it working better and faster. It currently takes up to 4 hours to import some of the
larger files. I am working on rewriting this to improve the efficiency but while at it, I was thinking of other ways to accomplish this outside of IIS. Some other members of the team are thinking it would be best to keep this in IIS for ease of deployment,
but I was thinking of moving it into a Windows Service. If keeping it in IIS is a viable option, I would like to go with that to keep the team happy.
If moved to a Windows Service, the import file would still be loaded through our internal website and the file path and parameters would be saved to the DB and the file would be moved to a share with a unique name (this is the current process). Then either
a FileSystemWatcher or Timer would be used from the Windows Service to start the actual file import.
I have some reservations about keeping this long running process in IIS, but we were able to come up with workarounds for most of them. Before I get started on this, I would like be reassured that this will be safe and efficient in the long run. What
do you guys think? Do any of you do large file processing in IIS? Is this going to be a maintenance headache?
Issues that I can think of with using IIS that will not occur with a Windows Service:
Jun 15, 2012 04:26 PM|Sparkers|LINK
Writing a service for this is a better option..
I ahev worked on projects where we have to do a huge data import and export and I made use of the web services and made sure it runs during low or no customers.. Many of my projects did the data exchanges between the db's so I had to choose the timings which
Now, you can use the web services and also if you can export the file to a location other than your prod server then it would be a good..