Forum Moderators: phranque
Thank you,
I just had this same problem so I switched to what I think is a more reliable host, a telecommunications company that actually owns fibre and doesn't provide shared hosting for pr0n sites (it took forever to get set up with them, made me wonder about their service...) The site is much faster now.
Having said that, yesterday, a week into the new service, I did catch the server down. Tech support said 'it was the first time he'd seen that in the two years he had been working there.' Hmmm. So I signed up to a service that checks site uptime. So far so good on the new host but I see that on my old host, one of my sites was down between 4:30-5:00am. Interesting... I will continue to monitor. I will probably have to go to a dedicated server one day but know nothing about managing servers and don't want to pay for it now.
it is what is going on with the other 50 sites on her shared host. Something she has no control over.I still think it is worth considering if she makes enough bank from the site, and particularly if she lives off the income from the site. Those 60 visitors could be buying $500 dollar products, hence making the expense of a cheap dedicated (or virtual dedicated) server a non-issue.
You can get a virtual server for quite a bit less than a dedicated server. Make sure that you choose a virtual server (such as one based on Xen) that gives you a guaranteed percentage of CPU resources. Ask your host how many virtual servers are on each machine.
With shared hosting, you just have no control over what other users are doing on the machine, and no protection from their actions. You are relying only on the vigilence of your host to monitor the server.
Are those 60 visitors as reported by Google Analytics? GA, naturally, only knows about visitors with JavaScript enabled.
Do you have a series of pages on your site that other site operators may want for their own use?
You may want to examine the server logs for evidence of your site being scraped by robot agents. They will typically have no regard for robots.txt or meta declarations, and certainly have no regard for whether your server can handle their crawl rate.
On several sites I've managed, I had to create throttling scripts to deny requests that were judged automated beyond a doubt, based on the rate of incoming requests from that IP & agent (and some other factors).
Before implementing a traffic control method, the sites affected would be extremely slow while they were being ravaged, or go down completely (the Access-driven ones I'd inherited). This was all on a VPS with a very solid host, by the way.
It may also be that, despite no ill intent, some legit robots are having the same effect while crawling your site. You may want to look into using crawl-delay in robots.txt, though not all bots will honor it, despite honoring robots.txt directives in general.
Pretty much any slack in optimization will be grandly multiplied when you're getting an enormous amount of requests all on top of each other. And when there's not a human driving those requests, that can be a very large amount indeed.
Since you're on SHARED hosting, someone else could be using up too much of the server's resources causing the site to lag. That someone could actually be YOU if your site is being spidered by Google/Yahoo/MSN and they're hitting it quickly so adding a "crawl-delay: 2" into robots.txt will help with 2 of the SE's.
Another thing to be wary of is that some shared servers that supply same-server web and email accounts that offer features like server-side anti-spam and anti-virus can practically grind the server to a halt when one of the customers is getting hit with a spam dump.
Last but not least, every other hosting account on a shared box is an open invitation for the server to be breached. All of the PHP junk people install (blogs, CMS, etc.) they don't update and next thing you know one of them gets hacked, or the whole server does, and it runs slow when the hackers use your server as a botnet.
I could go on and on with other possible causes but the bottom line is:
Why do you put your business at risk sharing a server?
If you make your entire living off this website, like I do mine, you should get your own dedicated server ASAP. Even if it's the bottom of the barrel $99 dedicated server, and never look back.
There are too many factors to take into consideration when getting a dedicated server: do you know how to setup a server, secure it, update it, etc. I doubt the OP knows (no insult intended).
Why not leave this task to people that actually do this for a living.
With 60, or 100, or even 1000 visitors a day you do not need a dedicated server, you simply need a reliable hosting company.
I beg to differ as a reliable hosting company can only go so far to keep a shared server up to snuff, it's a disaster waiting to happen, been there, done that, will never do that again.
However, with that low amount of traffic (I missed that earlier) a shared server shouldn't be much of an issue except it will impede your growth.
As far as the page loads go every page is php and is querying the DB, about 90% of the page loads are for a heavily modified phpbb forum. This puts me up around 80% of my allowed SQL queries in a month. Can't say I've had a problem yet or anyone mention anything, in fact when asked everyone says is very quick and that's been holding up for about 2 years now.
Maybe I'm lucky I don't know... Anyhow if you're having problems with just 60 or even 500 visitors a day and you can't track it back to a problem with your site code I'd suggest it's time to look for another host.
Someone asked what I'm paying..14.95.
30gb available, not using nearly that much.
From everything that's been speculated about, and the posters who have pm'd me for my url and replied with suggestions...I do believe it's more of a code issue than a server issue. We're gearing up for some changes to the website soon, this time I have some ideas for the designer to specifically ask her to do or not. But cleaning up the code is top of the list.
One key measure is the variability in site response. If it's lightning-fast one time, and slow another time, that increases the likelihood that it's other sites on the shared server causing the problem.
Her host is probably oversold, but probably to the extent that her host allows PHP and mySQL or other database apps to be run -- I would guess that one bad app shouldn't be able to kill a server, but it certainly could slow it down.
To know for sure, it's important to know what her visitors are experiencing exactly -- ie: are they just getting poor straight disk based HTML page load times? or are only script-generated pages slow? or are the slow loading pages ones that are returning database results and thus need to consult another box or server.
So far, I wouldn't know where to go next -- sure you can go to the code developer and have them re-vamp the code for more performance, but it could be already optimized as much as possible and the performance issue could just be some poorly written code from a neighbor bogging down either the script server or the database server. Scripts (like PHP) can be bad because they run as a server module, so they share the same threads, RAM, and CPU as the host HTTPd and they can cause what would appear to be a bandwidth issue, when there's actually a CPU util issue going on. A database app. (like mySQL) with inefficient and large querying can also totally degrade the performance (response time) of what is otherwise a very strong performing box, especially when it shares a CPU with the HTTPd (that's also running scripts).
I'm sure the programmer can also help the investigation by adding some time stamps to their code that appears as comments in the output that can be viewed in the source (or logged) to "clock" performace of the app -- this would enable comparisons to be made between when things are running well and when they are not, and what parts of the code (script? database?) are being effected. The programmer needs to know this to know where the code can be streamlined if at all, and to decide if the app. and database should be external or not.
Then again, it could just be a bandwidth issue -- Caps effectively limit bandwidth over time, but they do not limit bandwidth in real time. Time-of-day issues often scream bandwidth problems when they occur during peak times, but it's sometimes difficult to seperate how much of the issue is the back-end apps that are also likely to be more active during the same times.
Ask your host for a 'top' report this will show you what is being used most on the server, most probably MYSQL and Apache but it might be something different.
[webmasterworld.com...]
if you're using Apache you can turn on Apache's server status reports, this will show you who is on the server, what they are doing and what sessions are open.
[httpd.apache.org...]
when your server is slow do a trace route from your PC to the server.
Start->Run
type cmd
type tracert <domain name>
compare the results with responce times when your server is good
[support.microsoft.com...]
Get your developer to change the code to static HTML where possible instead of dynamic.
Do you have a contact us form on your site? it might be getting hijacked by spammers. make sure all your contact us forms have a wobbly captcha image.
[en.wikipedia.org...]
Move to another host. I recommend one that uses Rackspace as they offer a 100% up-time guarantee, and they have good tech support 24/7 but it may cost more.
A pig or DNS test will not tell you weather a server is slow. An overloaded server can still respond to a ping test promptly but data retrival could be slow.
Best way to test server is, upload a simple page and try to test speed of that page ;)
