Server is slow as hell, often resets connection


I’m not sure what is the matter with my server, but it is currently several times slower than I am used to when serving any content - even static. More work-intensive pages that parse text files will take several minutes to load, and will in fact reset the connection very often.

Error log shows that the php.cgi executable broke off with “Premature end of script headers”. My guess is that the process gets killed.

My web/mysql servers are millhouse and tachibana, respectively. I’d send this as a support request, but the panel does not work properly for me at this moment.

(On an unrelated note, many of my pages are blocked by Websense. They claim that I share an IP with an “explicit” site - can this be fixed?)


What’s the URL of your site? Nothing’s come up on today.

Have you changed anything?

If you can’t use the panel, there’s another contact form. I think this is the URL:

The Websense issue is a drag. I get caught in it at times, too. You could ask Support to change you, but you could end up with the same problem on the next IP address. But that’s life when you’re behind a work/school proxy server.



The affected sites are, and

All are Drupal sites, and the third one has a very large database. That one doesn’t load lightning-fast in the best of times. However, after running a query logger I’ve found that page load can currently take between 15-30 seconds (counting only PHP execution) on all sites, with simple SQL queries taking several seconds to process.

Then, too, whenever Drupal’s package manager is accessed (a work-intensive page that has to parse several dozen module manifest files), the page sometimes returns an internal error.

There’s been a definite slow-down in the last few days without any obvious changes…

Edit: is pretty exclusively static, and is also slow. Page response used to be near instantaneous.


Have you logged onto the shell and checked your server’s load? It may be that one of your neighbors has started running a resource hog on your box.



Considering that even your static site is slow, I’d go with rlparker’s suggestion to check the load on your webserver. The database isn’t the primary issue, though there’s the remote possibility that it’s slow as well.



I’ve checked the web server load and found abnormally high values (load around 8-10), but currently can’t access the shell so these values are a few days old.

In any case, I realized that I was using CGI instead of FastCGI, so I took steps to change that. It “works” (as in, I didn’t break it completely), but it hasn’t really alleviated the problem.

Error message for broken pages is now a bit more detailed in the log:

[quote][Mon Jan 07 07:51:56 2008] [error] [client ] (104)Connection reset by peer: FastCGI: comm with server "/home//sites/" aborted: read failed, referer:
[Mon Jan 07 07:51:56 2008] [error] [client ] FastCGI: incomplete headers (0 bytes) received from server "/home//sites/", referer:[/quote]


Edit: “works”, “break completely”, and “alleviated” receive new definitions.

The fact is that shortly after switching to FastCGI, I’m getting internal errors like the one above for almost all my PHP page requests. Not quite all, but close. The pages work only if they require minimal processing - Drupal’s database-cached pages will get served to guests, while logging in as a user (which will bypass the page cache and force full rebuilds on all pages) is all but impossible.


I must say that in regards to my support request re “FastCGI makes my page slower” and “I’m running a surprising number of php.cgi processes, could you check what’s up” I’d have expected a little more than “shared servers aren’t that great, but for a little extra you can upgrade to our dedicated server”.

My last host used to give me that spiel whenever I had any problem they couldn’t/didn’t want to fix (from installing PHP5, over shell access, crons, Python, CGI:IRC to getting more databases/performance), and ultimately that was one of the reason I abandoned them in favor of Dreamhost. When I want to upgrade my plan, I’ll ask Sales instead of Support.

I’m not really angry, just a bit disappointed. I’ll be first to admit that shared servers are slow and that Drupal tests the limits of PHP efficiency - that’s pretty much a given. But when switching from CGI to FastCGI makes the problem worse, something is definitely wrong, and I’d like to fix that problem before trying alternative methods to boost performance…