Long Load Times - cron.php

[TacticalNuke]

Google Webmaster Tool's has been reporting long site load times so I had my host take a look. I was told they used firebug to look at the site and most of the time it was loading quickly but occasionally would take 6 seconds or more to load. In all cases apparently cron.php was the culprit for the long load times. Is there a way to rectify this issue?

[Lynne]

Which cron job is taking all the time? You'll need to find that out first. If you have an active board, then looking at the time of the hang will tell you want cron job by looking and seeing which task is supposed to run at that time.

[TacticalNuke]

Thanks for the quick response, Lynne. I sent an e-mail to my host and here's the response I received (edited for brevity):


This wasn't a cron job being run by the server, it was a file called cron.php being loaded by your home page during the page load.

That is the culprit. I'm afraid I don't know what cron.php does though.

This is interesting because I recently switched from a shared server to a VPS server with a new host. With my old host, I was getting page load times of about 1.5-2 seconds with this kind of traffic. Now I'm at 3.0 seconds and that's no good at all, especially because ostensibly this VPS should have significantly more resources available.

[sheppardzwc]

This is interesting because I recently switched from a shared server to a VPS server with a new host. With my old host, I was getting page load times of about 1.5-2 seconds with this kind of traffic. Now I'm at 3.0 seconds and that's no good at all, especially because ostensibly this VPS should have significantly more resources available.
There are two types of cronjobs out there; one is at the system level that the server actually does, and one is at PHP's level which is done when a page is loaded. Most of these are small and are just cleanup tasks, but a modification you installed recently could be the culprit, or your VPS is just not up to par for it. Your host isn't going to be able to help you with this issue most likely though other than looking at logs; most don't know vBulletin and aren't trained in it, therefore have no idea what it is or if they do, don't know it's inner workings. In some cases if you purchased a low-end VPS you get less power - I found this out the hard way. With most shared servers while you're sharing the resources, they are significantly more powerful servers and aren't segmented like VPSes are, therefore you get more resources if you're with a trustworthy provider. Of course, not saying VPSes aren't powerful as if you're with a good provider they can be an indispensable alternative to dedicated servers.

[Lynne]

cron.php runs any number of 'cron' jobs - they are called Scheduled Tasks if run by vBulletin. As stated before, you would need to know what time the job was run in order to figure out which of the Scheduled Tasks it is that is at fault. But, as mentioned above, they are usually small tasks and shouldn't be causing any problem at all if you left them as they were when you first installed vbulletin.

[TacticalNuke]

Thanks to both of you for the explanation on that. I suppose it's likely the VPS as I haven't changed modifications at all since I moved over (and before then I hadn't changed them for a long, long time). The host is WiredTree, though, so it's definitely one of the better ones. Of course, I moved from ASmallOrange and I guess they were just really good with their resources.

I checked cron.php and it was last modified 7/19/2009 so definitely nothing has changed there in a while.

This is a tough call now. I can't justify upgrading with this host if a $50/month VPS with 768 of RAM can't handle 825K pageviews in a month, especially as we'll have months coming up with 2 million pageviews. Hmmm, what would you all recommend?

[Lynne]

We aren't wondering if the cron.php file has changed - have any of your Scheduled Tasks changed? All of those tasks get called by the same file cron.php. You can't tell which one of the jobs was being run except by the time. Notice how each task is run at a different time. If the task causing the issue is run at 0:00 server time, then it is most likely the Daily Statistics Log which runs at midnight (server time) every night. If the problem is at 0:01 (server time), the most likely the Birthday notices which go out at 0:01 server time every night. So, you need to know what time the problem is happening and compare it to the jobs you have running.

[TacticalNuke]

Should I be looking at stats in WHM, cPanel or elsewhere?

[Lynne]

Stats for what? You said your host said it was cron.php. So, ask them for the log that shows the times this is happening. Then look at your Scheduled Tasks in the admincp and see which task was running at the time your host says the cron.php file was causing problems.

[TacticalNuke]

After a bit of back and forth with my host, here's the only info I can get from them:

They used firebug to load the site and it loaded "very quickly" 24 out of 25 times. One of those times, though, it took longer than 6 seconds to load and the culprit was cron.php.

However, that information does not jive with my Google Webmaster Tools info as a 3 second page load average is very slow.

Apparently they cannot provide graphs of page load time and do not have anyone familiar with vBulletin (and I was told since it's a script issue, it's my issue and not theirs).

[Lynne]

And *what time* did they do this test? I keep telling you that in order to figure out which script it is, you need to know the time in order to figure out exactly which Scheduled Task ran. Have you looked at the list of Scheduled Tasks? How many do you have that are active? Are any of them not default vbulletin tasks? And have you changed how often any of them are run?

[kh99]

It may be useful to read this section of the vBulletin manual: http://www.vbulletin.com/docs/html/main/scheduled_tasks

[TacticalNuke]

Sorry about my apparent inability to get working on this, I've been mixed between talking to the host and trying to figure out things here.

Okay, so it appears that I'm basically on my own with this. I'm going to run my own firebug as well as look at the server logs that show spikes in activity.

I'll post up what the tasks are and how often they run. I think they're all standard but I could be incorrect.

[kh99]

Oh, sorry, my mistake - I guess the problem is really with figuring out exactly what time the delay happened and not with knowing what tasks you have running.

[Lynne]

The problem is he needs to locate exactly which scheduled task is causing the issue.