Hahaha, digg ruined a site on dathorn

[Buddha]

Some people seem to be spending a lot of time worrying about being suspended. Time that would probably be better spent optimizing their sites. The optimum share server site is static HTML and little or no graphics. The closer you get to optimum the less you have to worry about.

[AndrewT]

So there's no way to know until the account gets cut off?

There's no way to know until there is a problem. Whether or not that warrants a warning or suspension depends on the situation. This is not as cut and dry as everyone is making it out to be.

[cathode]

Some people seem to be spending a lot of time worrying about being suspended. Time that would probably be better spent optimizing their sites. The optimum share server site is static HTML and little or no graphics. The closer you get to optimum the less you have to worry about.

Gathering more information about a problem increases preparedness.

It is often completely unrealistic to remove graphics from client's websites and remove their database-driven features.

[AndrewT]

Graphics really aren't even much of a problem. The first thing to cause problems will be a Perl or PHP script and database activity. That is why it is important that these scripts are coded in the most efficient way possible. Poor optimization just multiplies the problem as the domain receives more visitors.

[george]

Graphics or other stuffs are simply static contents could be saved in a large amount of cache servers around the world, hosted in almost all ISPs we using every day, thus most of your HTTP requests to your site even no touch with the server. But for script programs and database (dynamic contents) they must get from server and consume CPU/Memory that could make a shared Linux server much lower definitely. Unfortunately they're the only cheapest ways for low-pricing web business right now.
In my experiences, CPU/Memory average under 20% or so always means it could answer HTTP requests fast, 30-40% a little bit lower, and 50-60% will be a terrible condition that hardware required to be upgraded. Thanks Andrew to double our memory.

[AndrewT]

RAM is not even an issue in 99% of theses case either. Poorly coded scripts running MySQL queries left and right will kill a server load with disk I/O alone. Disk I/O is by far the limiting factor in most shared hosting environments as there is only such much you can do. This is why we've started switching to SCSI drives, and they are performing much better than our IDE/SATA counterparts. However, any poorly written site with enough traffic can take down any server you throw at it.

[Stelex]

How are the servers coping with Wordpress blogs ? Would a WP blog that gets 10.000 hits a day (when digged) be a problem. The page content is purely text and few rather samll images but the WP is db driven itself.

[samsam]

It depends

How are the servers coping with Wordpress blogs ? Would a WP blog that gets 10.000 hits a day (when digged) be a problem. The page content is purely text and few rather samll images but the WP is db driven itself.

I imagine the answer would be: it depends.

Many sites that use Wordpress or [name your favorite blog or CMS or forum package] will perform differently under the same traffic load, according to a number of factors that boil down to how they are set up and managed.

I used to run a Mambo [CMS] site, for example, on Dathorn. Out of the box, and with some of the standard templates, it was not a good performer.

The standard template generated about 20 database calls per page view, and often much more. For example, the standard template (and page code) did stupid things like call out of MySQL the site name for every PHP page load, when that wasn't really something that varied at all and could be hard-coded into the template HTML.

After I simplified things and got each page load to only make about 5-8 (max) database calls, turned off some of the more useless modules, and did lots more optimisations, the site burned along and could sustain quite high traffic loads, even on Dathorn's grumpy old servers.

The same would apply to WordPress. You can't ask 'would a WordPress blog survive a Digging on Dathorn' without people really knowing what the site does in terms of for example the number of database calls per page, and other performance variables. If you turn on every bell and whistle in a product, in short, expect problems. Ditto for tools like Invision Forum or Mambo etc etc.

Every WordPress install will be different, according to how it has been setup. It might survive a Digging, it might not.