First php call is very slow (~ 2 mins)

Yeah, there are a couple of problems that given a casual glance appear to be the same problem. You’ve probably already worked out what that last problem was and what caused it.

Do you have a couple of websites that the original (PHP) issue seemed to be more prevalent on? I tried something that gave good results and it would be interesting to see if you record any difference using this method with your test scripts by comparing results against the historical data you’ve amassed. Email me if you’re interested in having a crack at it.

Hmm … but I haven’t worked it out at all! I have little idea of what is going on behind the scenes. All I know about it is pretty much what I’ve reported here. If you could elucidate what the problem was and what caused it, that would be great.

69.163.186.123 has recently been especially prone to repeat attacks of the original (>30-seconds-lag-on-first-php-call) problem, with 4 episodes in the last 30 days, on April 16, April 19, April 21, May 6.

Can you explain here what might be worth trying?

There are a multitude of posts in the forum that indicate which failing process causes that particular result. Funnily enough at least one of your posts in this thread (April 25th update) hinted that you realise which process is at fault.

If it doesn’t work in all situations then I wouldn’t want to waste another reader’s time having them try out something that “worked for me” just to find out that it doesn’t work for them (or they think it doesn’t when they get hit with the other issue which, as you’ve witnessed firsthand, has very similar symptoms). You were wasting your time on this already so I thought I’d extend the offer.

Further reply to support:

[quote]Hi, thanks for your response (May 5th).

Yesterday there was another prolonged slow-down episode (and this was clearly the ‘original’ problem, i.e. >30-seconds-lag-on-first-php-call, and not one of the other kinds of problem which have been mentioned here) on 69.163.186.123 starting May 12th 00:20 PDT and clearing after what I can only guess was an Apache instance re-start at 15:40 PDT.

That is 15 hours of website unusability. i.e. even though technically the website did not go down, it was unusable.

Checking the website with http://www.webpagetest.org/ produced a signature typical of this problem, i.e. ‘Load Time 38.6 secs’ (of which ‘First Byte 38.3 secs’) and ‘Repeat View 0.3 secs’

So here are 2 questions:

(1) As I’ve already mentioned, this particular website is unimporant. However I have several websites at Dreamhost where I do care about the uptime. Can I reasonably expect you to alert me if the problem recurs, and how long would it take before an alert arrives?

(2) It may be possible to keep the problem at bay by pinging websites from a cron job at less-than-6-minute intervals. This has been discussed in other threads, I could find the details if you wish. Would you recommend that customers do this for any sites that they care about the uptime of?

Thanks[/quote]

  • edit * corrected ‘April 12th’ to ‘May 12th’

Reply has arrived from DH support, in which they answer question 1 and refrain (maybe wisely) from answering question 2. They also mention a technical detail, something about thread counts, which could be a glimmer of a suggestion that an actual solution to the problem may be in progress. Cheers.

Hello, thank you for your reply (May 13th). Since then, on the websites that I’ve been logging at 10-minute intervals, there have been two more slowdown episodes (i.e. PHP calls consistently taking more than 30 secs):

on 69.163.192.103, starting May 15th 12:10 PDT until 17:20

on 69.163.186.123, starting May 16th 12:10 PDT and still continuing now (May 19th, 01:50)

Curious coincidence that both slowdowns started on different days at 12:10 PDT.

I took the opportunity to confirm the hypothesis mentioned in previous note (#24, this thread) that triggering PHP activity at intervals of less than 6 minutes turns off the slowdown, if FastCGI is enabled:

while leaving the original 10-minute cron jobs unchanged, I added (on another server) another cron job to call another PHP file on the same website at 3-minute intervals, and immediately the original cron jobs started showing no slowdown; after a couple of hours I turned off the 3-minute cron job, and immediately the original 10-minute cron jobs reverted to slowdown.

But I imagine you don’t really want customers pinging their websites at 3-minute intervals in order to keep them alive. So what would you recommend? My suggestion would be for Dreamhost to do something like that invisibly and automatically on each server (as a temporary solution while the engineering team is chasing down the problem) but as you have more insight into the overall situation please can you advise.

Couple of points. If they had an engineering team that was in a position to be able to fix it then it would have been fixed long ago, and you probably have more understanding of the problem than the people receiving your notes.