6 ms·

I've never used WP but I've read about it quite a bit. Usually it'd be after site X on HN goes down for not enabling caching and not being able to handle the lo

by sehrope 13y ago

I've never used WP but I've read about it quite a bit. Usually it'd be after site X on HN goes down for not enabling caching and not being able to handle the load. There's always links to "best practices for caching" or other tidbits. Out of everything I've read though nothing is as funny as wp-cron[1]. If you're not familiar with it then it's worth a read for a good laugh. See [2] for a nice article about it, in the meantime here's a summary: If you don't have a native cron installation (eg. shared hosting or Windows) you can config WP to act as a cron daemon (actually might be enabled by default). The catch though is since everything is WP is triggered by HTTP requests the way wp-cron works is to check if there is a job to run every time a WP page is hit. Yes you understood that correctly, every single page that is rendered also checks if it should fire off a cron job. The jobs get executed async in the background so it doesn't hold up the ongoing request but it has two interesting properties. 1. If your site gets a large influx in traffic the server runs wp-cron for every page hit and further slows things down. 2. If your site gets no traffic then it doesn't run at all. Funny eh? [1]: http://core.trac.wordpress.org/browser/tags/3.6/wp-cron.php http://core.trac.wordpress.org/browser/tags/3.6/wp-cron.php [2]: http://wp.tutsplus.com/articles/insights-into-wp-cron-an-introduction-to-scheduling-tasks-in-wordpress/ http://wp.tutsplus.com/articles/insights-into-wp-cron-an-int...

toble 13y ago
It's just a hack for people without access to cron. It was more of problem back in the day when hosting services didn't offer control panels and most wouldn't let you have command-line access. If you knew your hosting company well, you could maybe talk someone into setting up a cron job. I remember doing something similar for a stats script that would wipe old data every time it was viewed by an admin.
jacques_chester 13y ago
I used wp-cron as one of the motivating examples for a different architecture; I talked about it on HN last week -- https://news.ycombinator.com/item?id=6106248 https://news.ycombinator.com/item?id=6106248 Essentially, given the constraints of the LAMP architecture, wp-cron is the only way to do it. You overlooked that wrapping WP in layers of caching restricts wp-cron's supply of triggering events. It's a mess.
- sehrope 13y ago
  Yes that's exactly why it came about. I still find it very interesting (and humorous) solution though. I've seen the same inner platform effect in legacy systems at large corporations.
  - jacques_chester 13y ago
    I think of it as an architecture smell. Especially since LAMP is not the universal web app target any more. We can and should architect from the OS up.
    - sehrope 13y ago
      It's kludge plain and simple. It's ugly but it works (well kind of). That's the exact definition of a kludge. Further interesting things with wp-cron is that since other plugins make use of it, if you do have a "real" cron implementation the advice is to use the real cron to trigger wp-cron (via curl hitting a localhost only accessible page). Again, it's a kludge but it keeps things running. On the topic of new stacks from the OS on up, Docker[1] (and lxc in general) and CoreOS[2] are really cool. It's a much more elegant and long term solution to packaged, yet controlled, environments. [1]: http://www.docker.io/ http://www.docker.io/ [2]: http://coreos.com/ http://coreos.com/
      - e12e 13y ago
        Ironically, you could wind up without any where to run your cron jobs in such a setup as well... (eg: running scheduled tasks in the container as the db/cache/webapp uid). This is of course fixable, but still interesting given the context.
        justincormack 13y ago
        How? Crown is just a process that sleeps for a minute at a time, checks the config file, forks a process if needed and repeats plus some logging. The only reason WP does not implement that is because shared hosting will kill long running processes.
yogo 13y ago
Lol the inspiration must have come from the session gc, except it doesn't hurt if the gc isn't run due to a lack of page requests. On the other hand I guess something is better than nothing. I have had to use servers with real cron to execute scripts on servers without it to get around this.
8ig8 13y ago
Given the constraints, what are some better ways of implementing this?
- onli 13y ago
  There is none.
colinsidoti 13y ago
The glory of this system is that WP retains their stupid easy install. I suspect they pull down the data for whether a cron needs to be run in an initializing query that also pulls down a ton of other data (site name, for example). So in theory, they're only doing a few time comparisons of extra work per request. Also - I haven't looked too deep into WP's implementation, but are they actually doing it on page load? I've seen it in other php software (I believe phpBB) as a 1px image. This kinda solves the caching issues others are talking about...your server might still get hung up, and that picture might never load, but if you're cached properly I think it won't stop anyone from reading. Ignoring the bugs though...I've had my shared hostgator plan handle a couple of top page HN post with no additional caching installed, which makes me think it's probably not a problem for most people running WP. (I just double checked to make sure that's actually true, and it is.)
- rmccue 13y ago
  > I haven't looked too deep into WP's implementation, but are they actually doing it on page load? On page load (that is, when WP actually runs), WP fires off a non-blocking HTTP request to itself. This runs at maximum once per minute, and shouldn't actually run if you're using Super Cache or similar and hit a cache page.
  - jacques_chester 13y ago
    It's non-blocking on the page load, but it still ties up an additional PHP instance.
- jacques_chester 13y ago
  > So in theory, they're only doing a few time comparisons of extra work per request. And if a plugin has registered a long-running function, you're kinda screwed. > Also - I haven't looked too deep into WP's implementation, but are they actually doing it on page load? Yep. > I've had my shared hostgator plan handle a couple of top page HN post with no additional caching installed, which makes me think it's probably not a problem for most people running WP. HostGator install WP Supercache by default.
rmccue 13y ago
There's two options that could have been taken here. 1. On hosts that don't support cron, tell users to use an external service to do it, and in the meantime their scheduled posts and other functionality breaks. 2. Implement a workaround like this. Yes, it's not the greatest solution, but the point is that it works. In addition, "every single page that is rendered also checks if it should fire off a cron job" is incorrect. A lock is used to avoid running more often than once per minute. If you're at the sort of load where this is an issue, you should be running proper cron anyway.
chrisguitarguy 13y ago
It's easy to turn off: remove_action('init', 'wp_cron'); Then just set up your own real cron job to run the `wp-cron.php` script however often you'd like. > If your site gets a large influx in traffic the server runs wp-cron for every page hit and further slows things down. Which involves a single database hit and a `foreach` loop. Or, if you're using an external object cache (memcached, APC, etc), no DB hits. Probably not as dire a situation as it seems. This... > If your site gets no traffic then it doesn't run at all. ...is a huge problem.
- Pengwin 13y ago
  > > If your site gets no traffic then it doesn't run at all. >...is a huge problem. Why? If you are relying on things to happen at an exact time, them you should know not to use wp-cron. However, for the scope of internal wordpress tasks that don't need to happen every load, I don't see any problem with it happening when wordpress is prodded eventually, and the time it was scheduled to run at has passed.
oinksoft 13y ago
So ... you dropped by to take a pot-shot at WordPress? Request-based cron imitations have been around for a while particularly for software targeting cheap LAMP hosts (Drupal has an implementation, for instance).
wodenokoto 13y ago
How would you run cron without cron? And it only checks if it needs to run a job at page load, it doesn't actually run it everytime, which isn't that big of a deal to check. Wordpress has a very high focus on readable code which does seem to affect it's speed. But it is easy to use, setup and hack, which is why it is popular. And as Yahoo and wordpress.com clearly shows, it does scale.
- will_work4tears 13y ago
  If you have a hosting where you can't set a cron (most of the shared hosting I've used has crons though) you can use a free service like https://www.setcronjob.com https://www.setcronjob.com (not affiliated).
will_work4tears 13y ago
It's easy enough to disable the built in wp-cron and write your own cron that hits the wp-cron file on your own intervals. This is what I've always done on my WP sites. It's a hack, sure, but I too think the wp-cron thing is rediculous.

by sehrope 13y ago

toble 13y ago

It's just a hack for people without access to cron. It was more of problem back in the day when hosting services didn't offer control panels and most wouldn't let you have command-line access. If you knew your hosting company well, you could maybe talk someone into setting up a cron job. I remember doing something similar for a stats script that would wipe old data every time it was viewed by an admin.

jacques_chester 13y ago

I used wp-cron as one of the motivating examples for a different architecture; I talked about it on HN last week -- https://news.ycombinator.com/item?id=6106248 https://news.ycombinator.com/item?id=6106248 Essentially, given the constraints of the LAMP architecture, wp-cron is the only way to do it. You overlooked that wrapping WP in layers of caching restricts wp-cron's supply of triggering events. It's a mess.

sehrope 13y ago
Yes that's exactly why it came about. I still find it very interesting (and humorous) solution though. I've seen the same inner platform effect in legacy systems at large corporations.
- jacques_chester 13y ago
  I think of it as an architecture smell. Especially since LAMP is not the universal web app target any more. We can and should architect from the OS up.
  - sehrope 13y ago
    It's kludge plain and simple. It's ugly but it works (well kind of). That's the exact definition of a kludge. Further interesting things with wp-cron is that since other plugins make use of it, if you do have a "real" cron implementation the advice is to use the real cron to trigger wp-cron (via curl hitting a localhost only accessible page). Again, it's a kludge but it keeps things running. On the topic of new stacks from the OS on up, Docker[1] (and lxc in general) and CoreOS[2] are really cool. It's a much more elegant and long term solution to packaged, yet controlled, environments. [1]: http://www.docker.io/ http://www.docker.io/ [2]: http://coreos.com/ http://coreos.com/
    - e12e 13y ago
      Ironically, you could wind up without any where to run your cron jobs in such a setup as well... (eg: running scheduled tasks in the container as the db/cache/webapp uid). This is of course fixable, but still interesting given the context.
      - justincormack 13y ago
        How? Crown is just a process that sleeps for a minute at a time, checks the config file, forks a process if needed and repeats plus some logging. The only reason WP does not implement that is because shared hosting will kill long running processes.

yogo 13y ago

Lol the inspiration must have come from the session gc, except it doesn't hurt if the gc isn't run due to a lack of page requests. On the other hand I guess something is better than nothing. I have had to use servers with real cron to execute scripts on servers without it to get around this.

8ig8 13y ago

Given the constraints, what are some better ways of implementing this?

onli 13y ago
There is none.

colinsidoti 13y ago

The glory of this system is that WP retains their stupid easy install. I suspect they pull down the data for whether a cron needs to be run in an initializing query that also pulls down a ton of other data (site name, for example). So in theory, they're only doing a few time comparisons of extra work per request. Also - I haven't looked too deep into WP's implementation, but are they actually doing it on page load? I've seen it in other php software (I believe phpBB) as a 1px image. This kinda solves the caching issues others are talking about...your server might still get hung up, and that picture might never load, but if you're cached properly I think it won't stop anyone from reading. Ignoring the bugs though...I've had my shared hostgator plan handle a couple of top page HN post with no additional caching installed, which makes me think it's probably not a problem for most people running WP. (I just double checked to make sure that's actually true, and it is.)

rmccue 13y ago
> I haven't looked too deep into WP's implementation, but are they actually doing it on page load? On page load (that is, when WP actually runs), WP fires off a non-blocking HTTP request to itself. This runs at maximum once per minute, and shouldn't actually run if you're using Super Cache or similar and hit a cache page.
- jacques_chester 13y ago
  It's non-blocking on the page load, but it still ties up an additional PHP instance.
jacques_chester 13y ago
> So in theory, they're only doing a few time comparisons of extra work per request. And if a plugin has registered a long-running function, you're kinda screwed. > Also - I haven't looked too deep into WP's implementation, but are they actually doing it on page load? Yep. > I've had my shared hostgator plan handle a couple of top page HN post with no additional caching installed, which makes me think it's probably not a problem for most people running WP. HostGator install WP Supercache by default.

rmccue 13y ago

There's two options that could have been taken here. 1. On hosts that don't support cron, tell users to use an external service to do it, and in the meantime their scheduled posts and other functionality breaks. 2. Implement a workaround like this. Yes, it's not the greatest solution, but the point is that it works. In addition, "every single page that is rendered also checks if it should fire off a cron job" is incorrect. A lock is used to avoid running more often than once per minute. If you're at the sort of load where this is an issue, you should be running proper cron anyway.

chrisguitarguy 13y ago

It's easy to turn off: remove_action('init', 'wp_cron'); Then just set up your own real cron job to run the `wp-cron.php` script however often you'd like. > If your site gets a large influx in traffic the server runs wp-cron for every page hit and further slows things down. Which involves a single database hit and a `foreach` loop. Or, if you're using an external object cache (memcached, APC, etc), no DB hits. Probably not as dire a situation as it seems. This... > If your site gets no traffic then it doesn't run at all. ...is a huge problem.

Pengwin 13y ago
> > If your site gets no traffic then it doesn't run at all. >...is a huge problem. Why? If you are relying on things to happen at an exact time, them you should know not to use wp-cron. However, for the scope of internal wordpress tasks that don't need to happen every load, I don't see any problem with it happening when wordpress is prodded eventually, and the time it was scheduled to run at has passed.

oinksoft 13y ago

So ... you dropped by to take a pot-shot at WordPress? Request-based cron imitations have been around for a while particularly for software targeting cheap LAMP hosts (Drupal has an implementation, for instance).

wodenokoto 13y ago

How would you run cron without cron? And it only checks if it needs to run a job at page load, it doesn't actually run it everytime, which isn't that big of a deal to check. Wordpress has a very high focus on readable code which does seem to affect it's speed. But it is easy to use, setup and hack, which is why it is popular. And as Yahoo and wordpress.com clearly shows, it does scale.

will_work4tears 13y ago
If you have a hosting where you can't set a cron (most of the shared hosting I've used has crons though) you can use a free service like https://www.setcronjob.com https://www.setcronjob.com (not affiliated).

will_work4tears 13y ago

It's easy enough to disable the built in wp-cron and write your own cron that hits the wp-cron file on your own intervals. This is what I've always done on my WP sites. It's a hack, sure, but I too think the wp-cron thing is rediculous.