Gideon,

As an HMS Sales rep (though I was a tech for 5 years at HMS) and a CF programmer I'd like to address some of these points.

1. SeeFusion: When we implemented SeeFusion it was announced to all current customers as well as mentioned in our forums. The fact that it's not documented on our 'normal' site is an oversite that I'm having addressed now. It should be on the CF FAQ in our Support Pages within a week.

2. Sites Per Server: For CF sites the limit per server is 60% server resource usage, which is a bit variable but we've empirically (sp?) set at no more than 200 sites MAX. I'm sorry you received conflicting information from the rep you chatted with - my guess is that was a newer technician that didn't know he was allowed to divulge that information.

Regarding the 30 day money back guarantee, I would be happy to extend that to your site regardless of whether or not you've passed that point. The limitation of executing long queries was not meant to be sprung on you in this fashion, I assure you. Think of it this way - there is also nothing on our site that says you can't run a query that returns 1,000,000,000,000 records. Does that mean that if you coded an app to do that and found you couldn't we would be hiding the fact, and should list it on our site as a feature? No, it's simply something that was done to prevent abuse of the shared server environment by ALL of it's patrons, and in doing so has given us a much better control over the environment in general and the ability to give our clients better performance on the whole by addressing those clients with poor code who would normally cause problems for all on the server.

In your case I do want to point out that upload scripts are notoriously fickle, so I'm not saying yours was bad coding. Since the script has to run for the duration of the file transfer your network connectivity would then play a part in the length of the script, something that doesn't happen with any other type of cf scripting that I know of offhand. There is a similar limit on ASPupload files as well - about 15 megs if I recall, which has something to do with the fact that ASPupload stores the file in memory before writing to disk, so larger files would cause definite performance issues for your ASP site if we didn't limit that. Similarly you can only email 15 megs worth of data outbound from our network, since larger files (you guessed it) cause performance issues for the mailserver. These limits exist in EVERY well built environment...even gmail has a 10 meg limit on attachments if I remember correctly...but it's not often shown on the 'front page' when purchasing that service because it's not really a selling point, rather, it's more of a logical safeguard.

Jamie - thank you for taking the time to both discover my blog post and replying to it.

I'll reply to each of the points you brought up:

>>1.SeeFusion: When we implemented SeeFusion it was announced to all current customers as well as mentioned in our forums.

[Gideon] Yes, it was never told to any 'new' customers. In terms of forums, I had not used them, I was relying on your site and staff. I took a look, and yes, after searching, I see references to users talking about the limitation. But this is a corporate policy for your company, which should have been on the site. I'm glad you've taken action and feel it is important to add this to your FAQ.

>>2. Sites Per Server: For CF sites the limit per server is 60% server resource usage, which is a bit variable but we've empirically (sp?) set at no more than 200 sites MAX. I'm sorry you received conflicting information from the rep you chatted with - my guess is that was a newer technician that didn't know he was allowed to divulge that information.

[Gideon] My original post has the name of the staff person I spoke with. Although both the support person in chat AND the support staff in the email stated the same policy. It might be a good idea to send out a refresher to your support staff as to what the policies are.

>> Regarding the 30 day money back guarantee, I would be happy to extend that to your site regardless of whether or not you've passed that point. The limitation of executing long queries was not meant to be sprung on you in this fashion, I assure you.

[Gideon] Yes, I'm sure your company didn't 'decide' to limit our site, and were not looking to give people less than what they paid for. I appreciate your offer for the refund, but it looks like we'll probably need to scale up to the virtual server package you offer due to needing multiple domians pointing at the same site - and I don't think our current package will allow for this.

>> Think of it this way - there is also nothing on our site that says you can't run a query that returns 1,000,000,000,000 records. Does that mean that if you coded an app to do that and found you couldn't we would be hiding the fact, and should list it on our site as a feature? No...

[Gideon] While I understand what you are saying - the fact is, I'm a customer purchasing a service that is defined by levels/limiations. My disk storage, the number of email accounts, etc. These are all factors which define the package my client purchased. One of those factors is your SeeFusion 50 seconds rule. This too defines my package, it's a level/limitation/resource and no matter how it comes to light for the user... it's there and should be defined as a attribute of your package.

>>and in doing so has given us a much better control over the environment in general and the ability to give our clients better performance on the whole by addressing those clients with poor code who would normally cause problems for all on the server.

[Gideon] Maybe you could offer a certification process - for a small fee, you'd certify an app/site as high performance, and place it on the high performance servers.

>> In your case I do want to point out that upload scripts are notoriously fickle, so I'm not saying yours was bad coding. Since the script has to run for the duration of the file transfer your network connectivity would then play a part in the length of the script, something that doesn't happen with any other type of cf scripting that I know of offhand.

[Gideon] I've been running a social music site since 2001 which allows 20MB uploads to the server and have had over 20,000 files uploaded over the years - all on ColdFuison, from version 4 on up to 7. While upload scripts may be fickle in other languages, file uploads via ColdFusion quite basic. Again, the file in question wasn't even 1MB in size.

Last item - please serve a good error page at least - right now, SeeFusion simply CUTS the connection - as if the serve

I've had a number of users running into problems on HMS shared servers as well. The SeeFusion timeout can be a real pain to work around at times. I understand the need to kill processes that get stuck, but this makes it often impossible to run legitimate functions, like the upload function mentioned, or using cfcontent to send files down to the user. Other users have run into issues with running upgrade scripts where a lot of data is being migrated from one table to another, making it a far more complicated process to update their sites. It definitely needs to be clearly stated somewhere that this timeout exists. Even if they are worried about it hurting sales, it should be included in the welcome email so all new users know about it and can cancel within the 30 day trial period.

Even with SeeFusion in place, I still had issues on their shared server with pages timing out and often got low memory errors as well. They would always tell me that they were looking into the problems and would email the problem site(s), but invariably I would also be told that if I didn't want downtime on my site, I needed to upgrade to a VPS. I ended up moving to a host with low-cost VPS options and no longer have to deal with any of these timeout problems.