The issue with broken permissions on hosts/resolv/others has been fixed. It was due to a small (and short-lived) bug in our provisioning system. Thanks for mentioning us!
Hi Konstantin, there’s a couple things I’d like to point out that I hope you’d be willing to correct in your review. I understand that you had a bad experience with us and respect your right to voice it.
1) Running a cluster of 4 Mongrels will only cost $22/mo on our professional plan, and $26, $32/mo on our business and platinum plans, respectively.
2) On our site we outline that we’re selling (physical + virtual) memory in blocks of 50MB on shared servers — when Mongrels or Static FastCGI instances are fired up they consume (‘reserve’) these resources persistently.
Overall, and I suppose you’d have to take my word for it, your server ran into an unfortunate resource situation with a number of users who are now either suspended due to malicious behavior or upgraded to dedicated environments due to extraordinary growth of their apps. Most of our clients are having good hosting experiences with us and we’re working hard to maintain fast and reliable shared servers for Rails deployment at the lowest possible price.
William, thank you for your corrections and I appreciate that it must not be easy to maintain quality service at such a competitive price.
I’ve updated the pricing I mention and added a reference to your comment. I am willing to believe that our server may have been exception rather than a rule, and I hope that in the future you have a way to move clients off loaded machines quickly.
I had started with your free plan, and couldn’t complain about the responsiveness because of the price. When I upgraded to a paid mongrel-capable shared account, you moved me to another server with much less load, and initially the problems mentioned in my December 18, 2007 post (see below) diminished substantially.
However, as time went on, I began to see the same intermittent but frequent slowdowns and a few downright outages as I had on the free plan. Even my Mongrel-based Rails app would respond slowly at times.
The site monitoring service at siteuptime.com started testing my Mongrelized Rails app on HR by sending HTTP requests every half hour since mid-October. The reports I received indicate that there were multiple “failures” (generally at least 10 in each 24-hour period) intermixed with successful connections ON ALMOST ALL IF NOT ALL DAYS since October. When I personally attempt to connect, I generally get through, with some delay, so I suspect that these “failures” are mostly due to slow response and not actual downtime, However, this service has been monitoring a GoDaddy account (admittedly serving a static page) also since October, without a single failure report. And siteuptime.com reports 100% uptime regarding the same app under FastCGI on RailsPlayground since it was started on January 16. (The responsiveness of the app on Railsplayground is also significantly better than on HostingRails when I personally access it.)
Against this, I have had occasion to contact HR support a few times, and the response has usually been fast and helpful. Unfortunately, this can in no way compensate for an inferior service. So with regret …
Rob
October 17, 2007 at 10:35 am
Hi Konstantin,
The issue with broken permissions on hosts/resolv/others has been fixed. It was due to a small (and short-lived) bug in our provisioning system. Thanks for mentioning us!
-Rob at Rails Machine
kigster
October 17, 2007 at 11:49 am
Thanks Rob – I’ve updated the text.
William
October 18, 2007 at 12:22 am
Hi Konstantin, there’s a couple things I’d like to point out that I hope you’d be willing to correct in your review. I understand that you had a bad experience with us and respect your right to voice it.
1) Running a cluster of 4 Mongrels will only cost $22/mo on our professional plan, and $26, $32/mo on our business and platinum plans, respectively.
2) On our site we outline that we’re selling (physical + virtual) memory in blocks of 50MB on shared servers — when Mongrels or Static FastCGI instances are fired up they consume (‘reserve’) these resources persistently.
Overall, and I suppose you’d have to take my word for it, your server ran into an unfortunate resource situation with a number of users who are now either suspended due to malicious behavior or upgraded to dedicated environments due to extraordinary growth of their apps. Most of our clients are having good hosting experiences with us and we’re working hard to maintain fast and reliable shared servers for Rails deployment at the lowest possible price.
All the best,
~William at HostingRails
kigster
October 18, 2007 at 10:01 am
William, thank you for your corrections and I appreciate that it must not be easy to maintain quality service at such a competitive price.
I’ve updated the pricing I mention and added a reference to your comment. I am willing to believe that our server may have been exception rather than a rule, and I hope that in the future you have a way to move clients off loaded machines quickly.
eduardo
October 28, 2007 at 5:24 am
Try http://www.dreamhost.com
this should put all other hosting plans into trash
Edwin
January 22, 2009 at 8:02 pm
Dear William and other HostingRails Folks:
I had started with your free plan, and couldn’t complain about the responsiveness because of the price. When I upgraded to a paid mongrel-capable shared account, you moved me to another server with much less load, and initially the problems mentioned in my December 18, 2007 post (see below) diminished substantially.
However, as time went on, I began to see the same intermittent but frequent slowdowns and a few downright outages as I had on the free plan. Even my Mongrel-based Rails app would respond slowly at times.
The site monitoring service at siteuptime.com started testing my Mongrelized Rails app on HR by sending HTTP requests every half hour since mid-October. The reports I received indicate that there were multiple “failures” (generally at least 10 in each 24-hour period) intermixed with successful connections ON ALMOST ALL IF NOT ALL DAYS since October. When I personally attempt to connect, I generally get through, with some delay, so I suspect that these “failures” are mostly due to slow response and not actual downtime, However, this service has been monitoring a GoDaddy account (admittedly serving a static page) also since October, without a single failure report. And siteuptime.com reports 100% uptime regarding the same app under FastCGI on RailsPlayground since it was started on January 16. (The responsiveness of the app on Railsplayground is also significantly better than on HostingRails when I personally access it.)
Against this, I have had occasion to contact HR support a few times, and the response has usually been fast and helpful. Unfortunately, this can in no way compensate for an inferior service. So with regret …
Sayonara,
Edwin