Page 1 of 2 12 LastLast
Results 1 to 40 of 50
  1. #1
    Join Date
    Aug 2006
    Posts
    56

    Thumbs down Bad HostGator Experience

    I signed up about 8 months or so for the BabyCroc. The site had minimal traffic, so no real issues. Due to news relased, my site had a surge of traffic today. These clowns suspend my site with a message to "contact billing". Very unprofessional and doesn't look very good for my visitors. I call and the only way to remove is to upgrade to semi-dedicated. Even with that, they have no way to remove the suspension until after the transfer is complete. The guy says it'll take one hour to complete. 1.5 hours goes by and I call again. The rep says it'll take 12-24 hours to provision. Again, I ask if they can do something about the account suspension. She tells me it's due to abuse. Desptie repeatedly telling her it is due to a surge in traffic, she won't help. What type of company suspends your account and offers a 24 hour option to resolve it. I'm furious. You get what you pay for and Hostgator has lost my business.

  2. #2
    Join Date
    Oct 2003
    Location
    UK
    Posts
    3,375
    hi

    on your logs in CPanel how many visitors have you had today?
    Cyber Host Pro Ltd - over 10 years in the UK hosting industry.
    Website Hosting | Reseller Hosting | Cloud VPS Servers | Dedicated Servers
    ★ WhiteLabel OnAPP Cloud VPS Reseller Program, Failover, 10Gbit SFP+ Dual SAN storage with Cpanel, Plesk & Windows server.
    www.cyberhostpro.com - UK Call Centre + 24x7 Online Chat

  3. #3
    Join Date
    Aug 2006
    Posts
    56
    Because it was shut down for "abuse", I have no access via FTP or cPanel.

  4. #4
    Join Date
    Aug 2005
    Location
    Canada
    Posts
    838
    Although it's unpopular, many hosts may do that.

    Also, it's difficult for the host to tell if the site is determined hard core intentional abusers or accidental victim of sudden popularity.

    Another thing ANY hosting users are supposed to know (but not well known) is the fact that users are responsible for designing their site so that it respects TOS/AUP and server load condition.
    Actually, it's not easy considering many of today's popular apps are very resource intensive and they don't do well when massively accessed.

    Personally, I think it's the fault of entire industry, including the developper of the slow and heavy language (PHP) and apps, user community of these lang/apps who recommend/hype/push them, hosts who sell their plans showing how easy to use these heavy (and potentially dangerous) apps, and to some degree, users who just believe these people.

    Some hosts are implementing systems that reduces the risks of unintentional resouce abuse.

    I've been trying to promote lighter and more resistant languages and apps, and/or the use of at least caching and other techniques that can help.

    But majority of people (including hosts, developper, users) are either unaware or not very concerned, yet,
    even though this can hit anyone, anytime, as long as (and as soons as) they are exposing one of heavy apps to public...

    PS.

    This can happen to any shared host, most probably.
    Big or small, low budget or more expensive, it doesn't matter.
    Some hosts may handle it differently, though.

    Currently, the key for avoiding this type of unfortunate unintentional resource abuse is to construct your site as light as possible or put some sort of defense/protection mechanism in the apps or choosing a host/plan with lots of safety margins (and/or different policies).
    I do all of these.
    Last edited by extras; 01-09-2007 at 05:05 PM.

  5. #5
    Join Date
    Dec 2002
    Location
    texas
    Posts
    1,333
    What is your ticket number?

  6. #6
    Join Date
    Dec 2004
    Location
    New York, NY
    Posts
    10,574
    extras,

    You never really explain in detail what you think is a "faster" alternative to PHP. From what I've observed you simply like to have shell scripts that are called through a cronjob (or by user execution) that periodically generate the site and output static HTML. Now while that's great for sites like yours, it won't work for most sites. In the case of PHP scripts, they are generated every time they are executed - which is for every page load. If you had the shell script or perl equivalent of that, it would actually be SLOWER. [believe me, I've tried it.]

  7. #7
    Join Date
    Aug 2006
    Posts
    56
    Quote Originally Posted by hostgator.com
    What is your ticket number?
    Just sent via PM. Server was transferred. No FTP access via the IP address and no information was sent on how to set up my Nameservers. Just got off the phone with customer service and they couldn't help other than suggesting I submit another ticket. If you could help, that would be great. Missing a great opportunity each minute that passes.

  8. #8
    Join Date
    Aug 2005
    Location
    Canada
    Posts
    838
    Quote Originally Posted by layer0
    extras,

    You never really explain in detail what you think is a "faster" alternative to PHP.
    To be honest, I'm a bit tired of your categorical declaration like this.
    Have you read ALL my posts? Otherwise, how you can know that I NEVER realy explained?

    For the language, PHP is known to be slow in the shared hosting environment (partly because many shared hosts are running it as CGI, for security reasons).

    Perl is faster than PHP in many areas (unless heavy modules and OO are used).
    Python is also often faster than PHP, although it's not as fast as Perl.
    Ocaml/C/C++ are a lot faster/smaller than PHP, in general.

    Shell script can be faster, too, especially when you only need something simple.

    From what I've observed you simply like to have shell scripts that are called through a cronjob (or by user execution) that periodically generate the site and output static HTML.
    Your observation is limited or skewed or not well done.
    Although I like shell scripting, it's a rather limited language.

    I use Python/Ocaml/Perl, most often, but I've written some small scripts in PHP, too.


    Now while that's great for sites like yours, it won't work for most sites. In the case of PHP scripts, they are generated every time they are executed - which is for every page load. If you had the shell script or perl equivalent of that, it would actually be SLOWER. [believe me, I've tried it.]
    Well, that proves you don't know very well.

    You can verify the performances of languages in the shootout, for example.
    http://shootout.alioth.debian.org/gp4/

    It's a great site for learning different optimization tips (for each language), too.

    Note: If you want to continue on the off topic subject, please create a new thread.
    (And it's not the first time I have to tell you this.)

  9. #9
    Join Date
    Aug 2006
    Posts
    56
    I cannot believe this. I understand why hosting companies might post "acount suspended". I don't understand why they cannot remove it and bring a site back online. Until my site resolves, I'm screwed. I've been spending 8 months building my site up for today and this.

  10. #10
    Join Date
    Aug 2005
    Location
    Canada
    Posts
    838
    Because abuse department is involved in this type of thing, at many hosts,
    the process can be long ..... unfortunately.

    What you have described at hostgator is actually better/quicker than some other hosts I've used, where the abuse department only works during business day, and they were rather slow.
    You can imagine the frustration of users in this situation, even though theorically it's the fault of users.

  11. #11
    Join Date
    Dec 2004
    Location
    New York, NY
    Posts
    10,574
    To be honest, I'm a bit tired of your categorical declaration like this.
    Have you read ALL my posts? Otherwise, how you can know that I NEVER realy explained?
    Out of the posts I've read, you've never explained it until now [and even now its fairly limited].

    For the language, PHP is known to be slow in the shared hosting environment (partly because many shared hosts are running it as CGI, for security reasons).
    That's great, but there are some hosts who run it as fastcgi - www.fastcgi.com -- or as an Apache module for greater performance. Throw in eAccelerator and you can make the performance even better. I have PHP developers working on crew, and we've developed a CMS that makes use of MySQL and excellent optimization -- long story short we can use it to serve PHP based pages as fast as static pages on some hosts like Dreamhost. So please don't tell me that PHP is a slow language, that is ridiculous.

    Perl is faster than PHP in many areas (unless heavy modules and OO are used).
    Python is also often faster than PHP, although it's not as fast as Perl.
    Ocaml/C/C++ are a lot faster/smaller than PHP, in general.
    Perl will run as CGI on most if not nearly all hosting environments out there. How is this fast?

    Your observation is limited or skewed or not well done.
    Although I like shell scripting, it's a rather limited language.

    I use Python/Ocaml/Perl, most often, but I've written some small scripts in PHP, too.
    That isn't a substantial part of my observation that you addressed. Are your pages being generated on the fly, or are you simply generating them periodically and outputting a cache?

    Well, that proves you don't know very well.

    You can verify the performances of languages in the shootout, for example.
    http://shootout.alioth.debian.org/gp4/

    It's a great site for learning different optimization tips (for each language), too.
    Cool site, *BUT* is that testing the languages as they interface with a web server, e.g. Apache, I think not. That's what matters in the end as I've touched on earlier with CGI.

    Note: If you want to continue on the off topic subject, please create a new thread.
    (And it's not the first time I have to tell you this.)
    You brought up the topic yourself;

    Personally, I think it's the fault of entire industry, including the developper of the slow and heavy language (PHP) and apps, user community of these lang/apps who recommend/hype/push them, hosts who sell their plans showing how easy to use these heavy (and potentially dangerous) apps, and to some degree, users who just believe these people.

  12. #12
    Join Date
    Jan 2004
    Location
    New York, NY
    Posts
    1,241
    Hi treoguy,

    Quote Originally Posted by treoguy
    She tells me it's due to abuse. Desptie repeatedly telling her it is due to a surge in traffic, she won't help.
    When 'she' says your account was suspended for resource abuse, she likely means it in the sense that your website received such a surge of traffic that your individual site was consuming/abusing an unfair amount of your server's resources. Sometimes web hosting companies will suspend a site/customer if the site in question is causing any degradation of service for other customers on that server.

    This isn't really all that uncommon, however, HostGator's staff should have been able to properly explain the situation to you, and inform you beforehand that the provision time would be anywhere from 12 24 hours. With that being said, HostGator is a quality company and I am sure they would be more than willing to try and work through this situation with you. I wish you the very best of luck!
    Thanks,

    Brendan Diaz
    Connect: linkedin.com/in/brendandiaz

  13. #13
    Join Date
    Aug 2006
    Posts
    56
    This isn't really all that uncommon, however, HostGator's staff should have been able to properly explain the situation to you, and inform you beforehand that the provision time would be anywhere from 12 24 hours. With that being said, HostGator is a quality company and I am sure they would be more than willing to try and work through this situation with you. I wish you the very best of luck!
    They originally told me 1 hour. Then they told 24 hours. Customer service on the phone hasn't been much help and my support ticket response is very slow. I do appreciate the forum member here looking into things, but haven't heard back. It's hour three and I'm stressed. I've seen domains resolve pretty quickly, so I'm holding out hope. I just wish someone at Hostgator could get on the phone and assist with my problems. Once I agree to move to a new server, they should remove the block.

  14. #14
    Join Date
    Aug 2006
    Posts
    56
    I just got off the phone with Hostgator. If I hear the word abuse one more time, I'm going to jump out of my window. It's not abuse, it's a surge. One that would be great if my site were up.

    Simply put, if you plan on having a possible growth spurt and don't want your site going down, then don't choose Hostgator. They only option offered was a move to a bigger server and wait for provisioning. I have an an afternoon of my readers seeing "Account Suspended, please contact billing". Doesn't look good for me. According to the rep, I should consider myself luck as it usually takes "48 hours". Somehow, I don't feel lucky. I'm just hoping the site resolves quickly.

  15. #15
    Join Date
    Aug 2006
    Posts
    56
    I received a call from one of the techs at Hostgator. I'm very impressed with his knowledge of the situation. He's also gone above and beyond. Still working on it, but wanted to update you on Hostgator.

  16. #16
    Quote Originally Posted by treoguy
    Simply put, if you plan on having a possible growth spurt and don't want your site going down, then don't choose Hostgator.
    Did you ask Hostgator what they'd do in that kind of situation prior to signing up
    with them?

    If you're thinking of moving to another host, you might as well ask them too.

  17. #17
    Join Date
    Aug 2006
    Posts
    56
    To follow up, they have taken steps to win me back. I'm real impressed with the gentleman I spoke with earlier this evening. I am in the unique situation of having a site that was doing fine on a shared hosting account that had a traffic explosion. HostGator has been working with me to move the site to a server capable of handling all of the traffic. Still not out of the woods, but it looks like I'll be running once the DNS propagates. I've asked the mods here to update this topic, as my thoughts on Hostgator have changed.

  18. #18
    Join Date
    Aug 2005
    Location
    Canada
    Posts
    838
    Cases like yours may change how the hosting industry handles unintentional resource abuse, slowly.

    Although a user with massive accesses can't be easily kept online unless the host has special setup, hosts can choose to show different messages for different cases.
    "Site too busy, please try later" type of message should cause a lot less upset.
    If hosts allow at least static contents, users can be more understanding, too.

    And this case illustrates the advantage of having a backup host, with Dynamic DNS or services like DnsMadeEasy.com.
    The downtime could have been limited to 15-30 minutes (for most users).
    Dynamic DNS or DNS with short TTL time could have helped in case of server transition within the host, too.

  19. #19
    Join Date
    Nov 2003
    Location
    Newport Beach, CA
    Posts
    2,920
    "Site too busy, please try later"
    That hasn't got anything to do with his suspension.

    he was suspended for abuse.

    It's a double edged sword. The onus falls on the site owner, and that's where the blame belongs. If you buy a package then have a huge traffic increase all in one day, and you haven't purchased the required resources to manage it, it's your fault.

    I highly doubt you're going to find any host that's going to research a huge traffic influx to see if it's an attack or just a really cool article......
    Show your reciprocal links on your website. eReferrer

  20. #20
    And this case illustrates the advantage of having a backup host, with Dynamic DNS or services like DnsMadeEasy.com.
    The downtime could have been limited to 15-30 minutes (for most users).
    or, rather then paying for 2 hosts, you could use just 1 good host (which would cost you the same or less then 2 hosts) that doesnt experience 15-30 minutes of downtime (and your range of downtime is a minimum if you catch the downtime right when it happens and happen to be awake and or in front of a PC to make the required DNS changes.

  21. #21
    Actually, it's not easy considering many of today's popular apps are very resource intensive and they don't do well when massively accessed.

    Personally, I think it's the fault of entire industry, including the developper of the slow and heavy language (PHP) and apps, user community of these lang/apps who recommend/hype/push them, hosts who sell their plans showing how easy to use these heavy (and potentially dangerous) apps, and to some degree, users who just believe these people.
    Nothing wrong with todays "popular" apps, what is wrong is the environments many are trying to host them in. "Massively accessed" is a problem for any script - heck, even for a static site - and even in a dedicated environment - but, I guess this depends on how you define "massively accessed"

    Personally, as long as its "accessed" within the plan limitations (ie 15 GB, or 50 GB or 1000 GB - then you cannot call it "massively accessed" as based on the purchased plan, and usually the corresponding "unlimited mysql" and "single click installation" of these scripts which you call "resource intensive" - a user has a reasonable expectation of utilizing the resources they purchased towards the use of these applications). If the environment cannot support these applications based on the packages you sold, they should not be provided as "single click installations" - only a provider offering massive amounts of transfer for some ridiculously low fee would call these "popular scripts" "resource intensive" and that is because they cannot fulfill their plan obligation and they need to hide behind their TOS to justify an account suspension.

    (I am not saying this is or isnt the case in this instance with hostgator, they do quite well and they have a consitant record of meeting and exceeding customer expectations - Its important that we consider something was wrong with this clients script - ie) subpar 3rd party componant or a compromised script from a user that failed to patch their script, etc..)

  22. #22
    Join Date
    Oct 2002
    Location
    EU - east side
    Posts
    21,913
    Unfortunately some find that Cpanel's default "suspended account" page puts them in an unpleasant/unfair light in the visitor's eyes. Effectively having their site down during this while doesn't help at all.

    The onus falls on the site owner, and that's where the blame belongs. If you buy a package then have a huge traffic increase all in one day, and you haven't purchased the required resources to manage it, it's your fault.
    I don't think it's that black and white. If a site unexpectedly gets featured on I don't know what TV show or website (or a news release is surprisingly successful) both the owner and the host can only react to the situation. Neither the customers nor the host wanted this complication to take place, neither can really be blamed for it. The only true blame may origin in the way they react - fair or not, fast or not etc.
    Last edited by ldcdc; 01-10-2007 at 01:45 AM.

  23. #23
    Join Date
    Nov 2003
    Location
    Newport Beach, CA
    Posts
    2,920
    The respsonsibility falls 100% with the site owner. If you think it's not black and white you need to read some ToS's
    Show your reciprocal links on your website. eReferrer

  24. #24
    Join Date
    Oct 2002
    Location
    EU - east side
    Posts
    21,913
    Still, the TOS isn't there to assign blame. It does not detail what is right, it is there mainly to protect the host (though at times it protects the customer as well). That's why "blame" is not a word I would use.

    For if the customer is to be blamed for the traffic the site receives, then he is to be blamed/at fault for any DDoS attacks that target it as well (when in fact the attacker is the real villain).

    Then again, this may very well be just my opinion.

  25. #25
    Then again, this may very well be just my opinion.
    Personally, I think your opinion is bang on..

    You cannot blame a client if they come under attack and you certainly cannot blame a client if their site gets hit with legitimate traffic (ie they became successful - that is afterall the goal)

    You need to have some flexibility in your shared environment to accomodate legitimate bursts - and especially for the scripts you make available for clients to use....

    Having said this, there is NO shared environment (or dedicated for that matter) that can accomodate unlimited bursting capabilities.... the only things that really varies is how it is handled by a provider and how much/long you can burst - and that will mostly be determined by the servers relative baseline load...

  26. #26
    Join Date
    Aug 2005
    Location
    Canada
    Posts
    838
    Quote Originally Posted by CartikaHosting
    or, rather then paying for 2 hosts, you could use just 1 good host (which would cost you the same or less then 2 hosts) that doesnt experience 15-30 minutes of downtime (and your range of downtime is a minimum if you catch the downtime right when it happens and happen to be awake and or in front of a PC to make the required DNS changes.
    Any host can go down, for one reason or the other.
    And it's not a bad idea to have off site backup.
    In fact many people recommend having one.
    A backup host can serve as both offsite backup and failover site, among other purposes.

    It increases the demand for hosting.

    It allow us to compare hosts, as well.
    If the primary host is very good, then the backup host can be less good/reliable, etc, too.
    Even having a small static site as an emergency failover site could have saved a bit, in a case like OP had.

    And automatic failover is relatively easy by using a service like DnsMadeEasy.com.
    Similar thing can be done with a bit of simple scripting, too.

    This is a win/win method for many people including hosts, IMO.
    (Bad hosts may not like the idea of users comparing them to other better hosts, though.)

  27. #27
    Join Date
    Aug 2005
    Location
    Canada
    Posts
    838
    Quote Originally Posted by CartikaHosting
    Nothing wrong with todays "popular" apps, what is wrong is the environments many are trying to host them in. "Massively accessed" is a problem for any script - heck, even for a static site - and even in a dedicated environment - but, I guess this depends on how you define "massively accessed"

    Personally, as long as its "accessed" within the plan limitations (ie 15 GB, or 50 GB or 1000 GB - then you cannot call it "massively accessed" as based on the purchased plan, and usually the corresponding "unlimited mysql" and "single click installation" of these scripts which you call "resource intensive" - a user has a reasonable expectation of utilizing the resources they purchased towards the use of these applications). If the environment cannot support these applications based on the packages you sold, they should not be provided as "single click installations" - only a provider offering massive amounts of transfer for some ridiculously low fee would call these "popular scripts" "resource intensive" and that is because they cannot fulfill their plan obligation and they need to hide behind their TOS to justify an account suspension.

    (I am not saying this is or isnt the case in this instance with hostgator, they do quite well and they have a consitant record of meeting and exceeding customer expectations - Its important that we consider something was wrong with this clients script - ie) subpar 3rd party componant or a compromised script from a user that failed to patch their script, etc..)
    Maybe you can understand this.
    The resources are limited and using heavier apps will consume them faster than lighter apps.

    PHP is a slow language. So PHP apps will hold the memory longer.
    And PHP uses more memory than some other language especially for small scripts.
    If it needs more memory and if it holds on to it longer, the server can run out of memory earlier.

    On top of that, many of PHP coders and users aren't even aware that PHP apps are heavy.
    When we are less aware of potential problem, we tend to make less effort for prevention of the problems.
    So, PHP apps are often less optimized and more vulnerable, IMO.

    If someone is using a small plan of a small host using small machine, you can imagine the impact of heavy apps combined with heavy traffic can
    It will be felt a lot more than on a big plan on more powerful machine (or a cluster).

    And if you compare a static site, a site using lighter apps, and a site with heavy popular apps, it's not hard to see that a site with heavy popular PHP apps would start experiencing problems with smaller amount of traffic.

    I think it's easy to see the disadvantages of slow heavy language and apps.

    By using better langauges/apps, we can reduce the risks of unintentional resource abuse like this.

    And by using a backup host, we have even more protection in case all the efforts were not enough.
    Last edited by extras; 01-10-2007 at 10:16 AM.

  28. #28
    I was with host gator for about 4 months. If anyone knows what 'digg' is, they should know what that can do to your traffic. Iv'e been dugg probably about 3 or 4 times. This sends a surge of thousands of visitors per hour.

    This can take a toll on any shared envoirentment. Fortunately, hostgator didnt let me down. The site stayed up, and it was all good.

  29. #29
    Join Date
    May 2001
    Posts
    348
    Quote Originally Posted by extras
    Maybe you can understand this.
    The resources are limited and using heavier apps will consume them faster than lighter apps.

    PHP is a slow language. So PHP apps will hold the memory longer.
    And PHP uses more memory than some other language especially for small scripts.
    If it needs more memory and if it holds on to it longer, the server can run out of memory earlier.

    On top of that, many of PHP coders and users aren't even aware that PHP apps are heavy.
    When we are less aware of potential problem, we tend to make less effort for prevention of the problems.
    So, PHP apps are often less optimized and more vulnerable, IMO.

    If someone is using a small plan of a small host using small machine, you can imagine the impact of heavy apps combined with heavy traffic can
    It will be felt a lot more than on a big plan on more powerful machine (or a cluster).

    And if you compare a static site, a site using lighter apps, and a site with heavy popular apps, it's not hard to see that a site with heavy popular PHP apps would start experiencing problems with smaller amount of traffic.

    I think it's easy to see the disadvantages of slow heavy language and apps.

    By using better langauges/apps, we can reduce the risks of unintentional resource abuse like this.

    And by using a backup host, we have even more protection in case all the efforts were not enough.
    I think you are seeing this issue up side down, no end-users or average web developers will and should care about it. This is the responsbility of the hosting SERVICE provider.

    This may be a concern for software house or pro developers, but definitely not a point for over 99% of website owners.

    The end-users choose/use a script base on its features and functionality, NOT to test, check and compare the performance of its tech core. It is not reasonable to expect them to do it.

    For normal web programmers, they choose the language/app NOT because it will consume less RAM or any other server resources. performance is NOT the single factor of choosing the RIGHT tech. machine to suit people, not people to suit machine.

    I can't agree more on CartikaHosting comment:

    "Personally, as long as its "accessed" within the plan limitations (ie 15 GB, or 50 GB or 1000 GB - then you cannot call it "massively accessed" as based on the purchased plan, and usually the corresponding "unlimited mysql" and "single click installation" of these scripts which you call "resource intensive" - a user has a reasonable expectation of utilizing the resources they purchased towards the use of these applications)."

    As long as an application/script is not banned by the host, the customers have no reason not to use it, as long as they like it.

    If a host doesn't like to or can't handle the situation, they should either:

    - stop supporting the tech
    - ban particular script usage
    - smaller their package offer
    - reserve more resource
    - load balancing or whatever solution

  30. #30
    Join Date
    May 2001
    Posts
    348
    Quote Originally Posted by viclopez
    I was with host gator for about 4 months. If anyone knows what 'digg' is, they should know what that can do to your traffic. Iv'e been dugg probably about 3 or 4 times. This sends a surge of thousands of visitors per hour.

    This can take a toll on any shared envoirentment. Fortunately, hostgator didnt let me down. The site stayed up, and it was all good.
    everyone in hosting industry should be very faimilar with dugg effects

  31. #31
    Join Date
    Aug 2005
    Location
    Canada
    Posts
    838
    Quote Originally Posted by eric418
    I think you are seeing this issue up side down, no end-users or average web developers will and should care about it. This is the responsbility of the hosting SERVICE provider.
    I don't think it's a good idea for you to speak for ALL end-users and ALL average web developpers.
    In fact you don't know them all, and I'm an end-user who careas about it.
    So, it's evident that what you just said isn't really true.

    Also, it can be the responsibility of host, user, or anyone, depending upon the contract/agreement, IMO.
    If you want to take the full responsibility (in canse you are a host), that your personal (or corporate) choice.

    I don't know why you want to focus on "what hosts/users should do", rather than possible solutions/alternatives for avoiding the case like OP had.


    What's wrong with using lighter/faster languages/apps?
    It's good for environment, good for site/server resistance and performance.

    End users are free to choose and run whatever on the server within TOS/AUP.
    If they choose to run lighter/faster apps, it's good for the host, too.

  32. #32
    What's wrong with using lighter/faster languages/apps?
    Absolutely nothing

    It's good for environment, good for site/server resistance and performance.
    Agreed !

    End users are free to choose and run whatever on the server within TOS/AUP.
    and here in lies the problem when the TOS/AUP is designed to not allow users to utilize what they have purchased (ie 1000 GB transfer with single click installs). If those scripts cannot be accomodated and are "too heavy", dont offer them - this would require honesty though - and its much easier to hide behind a restrictive TOS and claim that any downsides to overselling are a myth and only mentioned to create fear

    I can name many environments where users can utilize all of their transfer towards an application you would call "heavy" without hitting any TOS limitation...

    Can you name any script within a script installer that a host offering 1 TB or 2 TB of transfer will allow to utilize their entire allotment towards that script without triggering a TOS CPU limitation?

    If they choose to run lighter/faster apps, it's good for the host, too.
    Agreed !!

    However, the average consumer will choose to run what is made available to them and they have a reasonable expectation of utilizing what they purchased without hitting TOS restrictions.

    I was with host gator for about 4 months. If anyone knows what 'digg' is, they should know what that can do to your traffic. Iv'e been dugg probably about 3 or 4 times. This sends a surge of thousands of visitors per hour.

    This can take a toll on any shared envoirentment. Fortunately, hostgator didnt let me down. The site stayed up, and it was all good.
    and that is the difference - and good on hostgator. Many of todays shared environments cannot accomodate such bursts because they are oversold to the extent of being overloaded - and once a servers baseline is overloaded - it has zero flexibility to accomodate any bursting - and suddenly normal scripts, which run fine on 1000's of servers are suddenly too CPU intensive...

    Once again - great news for hostgator customers when you see reports like this...

  33. #33
    It increases the demand for hosting.
    Not really, it increases the expectation for low quality hosting. The day we decide that it is necessary for everyone to have a backup host - then all credibility is lost in this industry IMO

  34. #34
    Join Date
    Aug 2005
    Location
    Canada
    Posts
    838
    Quote Originally Posted by CartikaHosting
    and here in lies the problem when the TOS/AUP is designed to not allow users to utilize what they have purchased (ie 1000 GB transfer with single click installs).
    Users have purchased what TOS/AUP offers.
    So, what you are saying is a contradiction.
    If TOS/AUP doesn't allow something, evidently that's not what users have bought.

    I know you argued that it's the fault of some hosts if they don't provide corresponding CPU/Memory/Database resources to go with the bandwidth and disk space.
    But there is no such law nor standards.

    In fact, I'd rather see different hosts offering more (or less) of different resources.

    One host might be offering lots of CPU and not much of other resources, while other host may be offering lots of disk space only, for example.

    If you want to offer "specificly well balanced resources for popular slow/heavy apps", that's your choice.
    Other hosts can offer whatever they want.


    And users are free to choose whatever they like.
    We can choose to combine some hosts to obtain better deals, better performance, better reliabilities, and so on.
    There are many possibilities.

    We don't have to be narrow minded.


    If those scripts cannot be accomodated and are "too heavy", dont offer them - this would require honesty though - and its much easier to hide behind a restrictive TOS and claim that any downsides to overselling are a myth and only mentioned to create fear
    I don't know to whom you are talking.
    I don't offer hosting.

    And if you are starting AGAIN to suggest that someone has said something without quoting her/him, you may want to be more careful not to repeat this so often in a public forum because you have often misquoted others.


    I can name many environments where users can utilize all of their transfer towards an application you would call "heavy" without hitting any TOS limitation...

    Can you name any script within a script installer that a host offering 1 TB or 2 TB of transfer will allow to utilize their entire allotment towards that script without triggering a TOS CPU limitation?
    Again, hosts offer what they define with their TOS/AUP.
    There is nothing wrong with respecting TOS/AUP.

    Also, if a host pretend that any script can use up the bandwidth without causing any problem, I wouldn't take them so seriously.

    As I'm not in favor of heavy/slow apps, I'm naturally not in favor of one click installer for them, either.
    But if a host offer them, that's their choice and also it doesn't make that host better/worse, in a general sense, IMO.

    Moreover, even with the hosts you may want to name for some reason, faster/lighter apps would be more resistant and better for the server/host/neighbors.


    However, the average consumer will choose to run what is made available to them and they have a reasonable expectation of utilizing what they purchased without hitting TOS restrictions.
    If we apply your way of thinking, hosts shouldn't be offering even the static contents because even they can cause server problem if the site gets huge traffic.

    Do you blame car manufactures for selling something that can go over the speed limits?
    And the speed limit in the city can be pretty low.
    Also, each county/municiplity can set their own limits.
    It's not the fault of municipality not offering higher limits nor the fault of car manufactures.
    They can inform drivers more of the risks, though.


    Again, my focus has been preventing the pain.
    And in this thread, I was mainly talking about what users can do, by themselves.

    Somewhat, some of you opposed simple and cost effective alternatives like using backup hosts, or lighter/faster languages/apps.


    Quote Originally Posted by CartikaHosting
    Not really, it increases the expectation for low quality hosting. The day we decide that it is necessary for everyone to have a backup host - then all credibility is lost in this industry IMO
    You don't have to be afraid of "loosing credibility", just because some users decide to use backup host.
    It's not that dramatic.
    (Unless you love to make doomsday prophecy ... to scare others. )

    Also, you have to have the credibility before to loose it.

    And frankly, again, I have been focusing more on "solutions/alternatives" for preventing pains and suffering caused by these unintentional resource abuse cases than worrying about "credibility".
    Last edited by extras; 01-10-2007 at 10:05 PM.

  35. #35
    Leaving all of the erroneous comments meant to initiate a conflict aside, I will address the 1 or 2 points of yours that is relavent to the conversation:

    In fact, I'd rather see different hosts offering more (or less) of different resources.

    One host might be offering lots of CPU and not much of other resources, while other host may be offering lots of disk space only, for example.
    Exactly correct - contradicts what you have previously said that certain hosts can accomodate everyone - but, every conversation/dispute I have had with you specifically focusses on this point - and that is that different business models exist for a reason and cater to different audiences with different needs - thank you for finally agreeing with that simple, yet somehow complicated statement

    I know you argued that it's the fault of some hosts if they don't provide corresponding CPU/Memory/Database resources to go with the bandwidth and disk space.
    But there is no such law nor standards.

    If you want to offer "specificly well balanced resources for popular slow/heavy apps", that's your choice.
    Other hosts can offer whatever they want.
    Seems to be the final sticking point between us extras - maybe we can overcome this and find a peaceful harmony...

    It is not the scripts fault that environments are too overloaded to accomodate their utilization of these scripts. If a providers environment cannot accomodate these popular scripts based on their business model, they should clearly state the limitations of their packages with respect to these scripts, vs saying "unlimited mysql" and "1 click install of all of these scripts" + 1TB transfer, etc... It is not a stretch at all for that sort of marketing to be considered misleading to the public - or as its classicly known - "bait and switch" - which by the way, does have legal ramifications...

    << removed >> solutions like CMS, CRM and eCommerce - and just because you feel these scripts are slow or heavy is irrelavent - they are proven, reliable and affordable business solutions that customers of all sizes heavily use and rely on. Additionally, compared to many "enterprise grade" solutions, they are quite light on resource requirements and the hosting of these applications represents a much lower TCO to the average business owner (both in licensing fees, and required server resources)

    If an environment cannot support them, they need to be clear about that - and if they have such extensive TOS to prevent their usage beyound a small percentage of the plan allocations they are selling, they need to reveal that to the consumer...
    Last edited by writespeak; 01-12-2007 at 03:45 AM.

  36. #36
    Quote Originally Posted by CartikaHosting
    Not really, it increases the expectation for low quality hosting.
    Which is one reason why we have these kinds of threads.

  37. #37
    Join Date
    Nov 2003
    Location
    Newport Beach, CA
    Posts
    2,920
    Quote Originally Posted by eric418
    everyone in hosting industry should be very faimilar with dugg effects

    You're right. but that's clearly not the case. Hence replies in this thread like 'that means their oversold' if someone says you got dugg and it brought the server down.

    That will happen to 99.999999999% of shared environments because there is nobody profitable that could have anywhere near the kind of overhead it takes to get immediate hits from 10,000 users on a mysql database. the only reasonable way to even attempt to do that would be clustered servers with a ton of unused resource. That kind of traffic will immediately bring a dual xeon with 2 gb of ram to it's knees. I've seen it many times with dedicated customers that put tickets in that their server is down.
    Show your reciprocal links on your website. eReferrer

  38. #38
    Join Date
    May 2001
    Posts
    348
    dedicated servers are being dugg down daily

    for those to-be-dugg articles, non sql is the only way to go.

  39. #39
    Join Date
    Aug 2005
    Location
    Canada
    Posts
    838
    Quote Originally Posted by CartikaHosting
    Leaving all of the erroneous comments meant to initiate a conflict aside, I will address the 1 or 2 points of yours that is relavent to the conversation:
    This comment describes itself: "the erroneous comments meant to initiate a conflict".
    And it's irrelevant for the conversation, too.

    contradicts what you have previously said that certain hosts can accomodate everyone
    Quote "what I have previously said", please.


    Seems to be the final sticking point between us extras - maybe we can overcome this and find a peaceful harmony...
    You are honest in admitting that you are not peaceful with me.

    If you want to oversome your misquoting habit, please go ahead.
    I know it's hard for you to stop bad old habit.
    But maybe you can do it.

    This will improve the quality and credibility of your posts.


    It is not the scripts fault that environments are too overloaded to accomodate their utilization of these scripts. If a providers environment cannot accomodate these popular scripts based on their business model, they should clearly state the limitations of their packages with respect to these scripts, vs saying "unlimited mysql" and "1 click install of all of these scripts" + 1TB transfer, etc... It is not a stretch at all for that sort of marketing to be considered misleading to the public - or as its classicly known - "bait and switch" - which by the way, does have legal ramifications...

    << removed >> solutions like CMS, CRM and eCommerce - and just because you feel these scripts are slow or heavy is irrelavent - they are proven, reliable and affordable business solutions that customers of all sizes heavily use and rely on. Additionally, compared to many "enterprise grade" solutions, they are quite light on resource requirements and the hosting of these applications represents a much lower TCO to the average business owner (both in licensing fees, and required server resources)
    << removed >>


    If an environment cannot support them, they need to be clear about that - and if they have such extensive TOS to prevent their usage beyound a small percentage of the plan allocations they are selling, they need to reveal that to the consumer...
    If a host is showing TOS, it's already "revealed" to the consumer.

    And I guess we can expect to see all sorts of clear warnings in your hosting plan pages, if you are truthful to what you preach.
    If you ahow a good example and if it works, maybe other hosts may follow.
    Last edited by writespeak; 01-12-2007 at 03:46 AM.

  40. #40
    Join Date
    Aug 2005
    Location
    Canada
    Posts
    838
    Quote Originally Posted by eric418
    dedicated servers are being dugg down daily

    for those to-be-dugg articles, non sql is the only way to go.
    Maybe someone can write a Apache module that redirect/rewrite URLs based on the server/database load and/or delay.

    This way, user can have two (or even more) sets of contents.
    Normal contents and contents to be shown in case of higher server load, and why not for emergency.

    Doesn't RFC for HTTP have something like response code 911 ?
    It means server is in a trouble and it can show the default or user defined 911 error document.

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •