I have used Mosso on behalf of a client for several months now. I have not had any problems with performance, though there was one brief period (about a half hour) where the site was down. This was during the day on a weekday. Not quite up to Rackspace standards.

I have had many extensive chats with Mosso technical support. So far, every one has been satisfactory, even if the solution has been unexpected. For example, I found out that you have to delete, then reupload code files in order for changes to be visible. This is unexpected, undocumented and annoying when working on a website. Apparently, this problem (and it is a problem - it's caused by an incompatibility between their Linux storage and IIS) also applies to data files, such as XML files. Now, suddenly, something that was just annoying, is a big problem. It is not uncommon to store information in text files. For example, by default, the software that runs the blog you are now reading stores its information in text files. The problem is that changes are written to the files, but are not read back out - the previously cached version is read out. This makes it difficult to edit posts, for example, and makes the ASP.net App_Data directory unusable.

Mosso's solution to the problem: don't use text files to store data.

Patient: Doctor, it hurts when I do this.
Doctor: Don't do that!

Following is a transcript of my chat session. You be the judge! Notice that he first tries to blame II7, but under my withering gaze later admits the problem is with the design of their file storage system.

Ryan D.: Welcome to technical support. How can I help you today?
Tom: Hi - there is an oddity with your hosting system, which I've previously discussed with another tech.
Tom: Basically, whenever I want to change a file, I have to delete the file on your server, then upload a new file.
Tom: If I just overwrite an existing file, the change does not take place immediately or even quickly. I'm not sure if it ever takes place.
Tom: Are you familiar with this?
Ryan D.: I am.
Ryan D.: Is your site IIS or php?
Tom: IIS
Tom: This is causing a problem with implementing BlogEngine.net, which uses a file-based storage system.
Ryan D.: Within the control panel on the General settings tab at the bottom of the page there is a button called Rebuild Application.
Ryan D.: If you select the Rebuild Application button it will reload the pool and your changes will be made.
Tom: When somebody edits a post, the file is changed by the program, but the change does not display.
Ryan D.: Hmm. You may want to consider storing these files that you are going to be editing on the fly in your database.
Tom: I see that, but it's not really practical for a blog writer to have to login to the site's control panel and rebuild the application, is it?
Ryan D.: I would definitely agree that isn't practical.
Tom: I work with many different hosts - you are the only one I have ever seen that has this requirement. Is it related to this cloud computing business?
Tom: Even as a developer, it's pretty cumbersome.
Ryan D.: I am not sure that you should be experiencing this issue if they are just editing a blog post as the blog post should be stored in your database and updated automatically.
Ryan D.: If this is not the case you might consider storing the blog threads in the database.
Tom: I am sure they are experiencing the issue. BlogEngine.net has the option of storing in a file system (the default) or in a database. They like keeping the blog files apart from their e-commerce data.
Tom: You didn't answer my question about why you have to jump through hoops in the first place.
Ryan D.: It is actually an IIS7 application directory issue.
Ryan D.: The way IIS7 has application pools setup requires the application pool be restarted for any file changes this is as a result of the way Microsoft developed IIS7
Tom: Is there a Microsoft KB on this? I host on other IIS7 machines - at discountasp.net - and don't have to do anything special to see changes.
Ryan D.: I don't have any links to Microsofts KBs. You may have the setting on the application pool set to something really low which would be why you don't see it on your other solution.
Tom: I'm trying to Google this - I don't see any mention of it.
Tom: What do you mean - set to something really low? A time? What time is yours set for?
Tom: I'm not seeing changes after even a half day.
Tom: Plus - why would you have to rebuild the application to see changes in data files - xml files?
Ryan D.: I believe our servers are set to 20 minutes
Ryan D.: To xml you shouldn't
Tom: I do.
Ryan D.: If I was going to try to replicate the issue you are having how would I do this?
Tom: Go to http://xxxxxxxxxxxx.com/blog/post/VoIP-Business-Development.aspx
Tom: Click the login link in the lower right.
Tom: Login as xxxxxxxx / xxxxxxxx
Tom: Click to Edit the first post.
Tom: Make some small change.
Tom: When you go back to the post, you'll probably see the change.
Tom: Open a different browser, FF if you were using IE, go to the same post.
Tom: I don't see the change.
Ryan D.: I added # at the end.
Ryan D.: There were 3 now there are 4
Tom: I still see 3
Tom: You see the change in the browser where you made the change, but not in any other browser.
Ryan D.: You may need to clear the cache in your browser.
Tom: No - I've used this exact software in other sites - you don't have to clear cache - doesn't make sense - repeat visitors have to clear their cache to see your changes?
Tom: Even when I go to edit, I only see three #'s at the end of the top post.
Tom: There should be no cache issue there - it's reading the file to edit it.
Ryan D.: I see what you are talking about now. I also spoke to an admin to see if they have any feedback.
Tom: When I FTP down the datafile, I see the four #'s, though.
Ryan D.: The issue is that the file system is linux and when you over write the file it doesn't send a notice to windows that the file has changes so it continues to load the old file. This is the way the system is designed. Although it is designed this way it isn't intended to be and we are working on another method to allow for overwriting of files.
Tom: So this actually has nothing to do with IIS7 as you first stated?
Ryan D.: If you code to have the file deleted and then upload a new file with with the same name or if you have the file modify and named differently this will work. The other option being to run the blog from a database.
Ryan D.: It does.
Ryan D.: Because the file system is linux and the server your site is parsed through is windows there is a "cache" of information which rebuilding the application can also resolve.
Tom: Rebuilding the application doesn't bring me four #'s - I tried.
Ryan D.: Basically the issue has to do with the way the cloud environment works and the solution has to do with the IIS issue.
Ryan D.: Some files are not corrected by this method, this being a prime example of that.
Ryan D.: If it is an asp.net file it will not be effected by the rebuild.
Tom: There are lots of reasons to store data in text files. When you store data in text files, you usually store it in a particular file. This seems like a pretty big issue.
Tom: It makes the App_Data directory pretty much useless.
Ryan D.: I am checking with the admin for other suggestions however this being a known issue there isn't much I have as a way around this other then to use a database.
Ryan D.: Unfortunately it does appear that until this issue is resolved the only work around we have is to have the posts stored in a databsae.
Tom: Is there a time period for resolving the issue?
Ryan D.: I am not sure of an eta on when this issue is going to be resolved however we are looking into possible setting up a windows based file system as an alternative.