OK people, rather than you all speculate about what my position might or might not be, let me provide you with some information.
As noted above, my site is hosted by EKM. They're not a dedicated hosting company, so I don't think the quality or otherwise of their pure hosting offering is meaningful. But they are (I believe) the UK's biggest provider of e-commerce solutions. My web site is one of about 9,000 built using their tools, technology and templates. I believe they run their own servers in the UK but I don't know that for a fact and I don't really care.
The point of mentioning this is that I can't just transfer to a different host. I would need to re-design and re-build the web site from the ground up. It's a step I need to take one day, maybe soon, but it's not an easy fix.
The main metric EKM use to judge the size of their clients' sites is bandwidth. I think that's pretty reasonable. Bearing in mind that all the sites are built using the same tools and technology, and they're all e-commerce sites. Yes, some will have larger page sizes than others, but nobody running an e-commerce site wants to have huge pages, so there won't be orders of magnitude of variation here. In this context, bandwidth is a fairly reasonable metric to use as a proxy for things like server resources etc.
EKM's "fair usage" agreement allows for 45 GB per month of bandwidth. My site is way inside that - in September I used 16 GB.
However EKM have pointed out to me that, whilst bandwidth is a reasonable proxy for other metrics such as server load, it's not infallible. After all 1,000,000 x 1kB pages will hit the server harder than 1,000 x 1MB pages. But they're telling me that, basically, my site is causing a disproportionate amount of work for the server.
Which is why I've been looking at page views and puzzling over this metric. Remember, all the sites on this server use the same tools and technology, so you would expect each of them to be generating broadly the same amount of load on the server per page view. And that's where I get confused. I simply cannot believe that my demand of 1 page view per 10 seconds will make any kind of appreciable difference to a "high spec" server which is only hosting 48 sites.
I know that doesn't sound much, but if each page takes 0.2 secs of CPU to generate, that's 2% of their resource.
That's true so far as it goes, but I don't believe the numbers can be anything like that. It's a high-spec server with 8 cores and umpety-ump gigabytes of RAM. It should be capable of serving dozens or hundreds of pages per second, surely, rather than just a handful. Shouldn't it?
You may not necessarily be straining the server on your own, but let's suppose your site is the busiest on the server by a good margin. All else being equal, you could be using several times the amount of resources as the next busiest site on the server. From the host's point of view, they might be able to fit on another few sites in place of yours if you were to be migrated to another server.
Again, that's true as far as it goes, but I don't believe it reflects the situation. If my site were the busiest by far, then what on earth is causing the server problems? Even if my site is only average for the server, that means the peak throughput is only 5 pages per second. It comes back to the fact that I believe a properly-configured properly-managed high-spec server should have a considerably higher throughput. Shouldn't it?
Bottom line, I've been challenging EKM to confirm that my demand of 6 pages per minute is enough for them to be concerned about. My common-sense view says that it's not a big proportion of the server resources, and certainly not enough to warrant an upgrade to a VPS. (For which I would pay an extra 650%, by the way. The basic EKM package is very good value but the VPS looks like very bad value.) Up until Wednesday EKM were insisting that my site was causing problems. Now since yesterday they seem to have changed their tune. I suspect they've discovered some sort of problem in their server infrastructure which is limiting the throughput. I've been promised a solution by Tuesday, but I'm not holding my breath.