The problem with the site crashing is that the game data is stored in XML which is then Zipped up to save space. This was an experiment on my part to see if this would be more efficient for storing lots of data that is infrequently accessed than putting the data into a database which is optimized for frequent data access. This would also allow for easier distribution of the files at some point -- some files could be on the server, others could be "in the cloud" (as they say). Whereas with a traditional (non Azure) MS SQL database, it all needs to be in one place.
If I were to do it again though, I don't think I would do it this way. The problem is that something is corrupting the game data on occasion when the data is being saved and zipped. Then when it goes to unzip the data the next time, it complains that it fails it's CRC check. This corruption seems to poison the .Net appdomain and it eventually crashes requiring a manual reset.
I am not quite willing to rewrite the whole game data storage engine at this point though. So I have updated to the latest version of the DotNetZip Library and modified the code a bit to detect when the zip file is corrupted and attempt to automatically repair it.
Hopefully this will cut down on the amount of corrupt game data and as a result make the appdomain crash less frequently making the site more stable.
Hopefully.
