I tried to submit the official Wordpress.org announcement and got "stop spamming us".
http://wordpress.org/news/2013/08/oscar/
Is Wordpress.org domain banned on HN?
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.
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.)
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).
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.
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.
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.
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.
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.
FWIW, I just tried to update my dev site, the install failed, and now the site fails to load. Yikes.
In all fairness, I think that's because the admin has been playing around with file permissions on the server side. I can't even log in right now to read the errlog.
This is exactly what plugins are for. Most people aren't going to need this, and for those that do, there's a tonne of plugins out there that will add this functionality for you.
Shipping caching by default would be a better start. The Wordpress team have said that the hosting implications of writing to disk make it a non-starter; but for some reason that didn't stop them from shipping auto-update or one-click plugin/theme installation in mainline.
I have to admit I'm surprised a community like HN would upvote such a vulnerable package. Hell, even our sites that have been converted to static HTML still receive requests for /wp-admin/ by bots all the time.
Thanks for allowing non-technies to set up their own site but no thanks--I'm good.
HN users often view PHP and those products built using PHP with disrespect. Sure they have their problems, but these products have been around for an eternity (in internet terms). Lots of programmers wouldn't have long standing careers without them.
[+] [-] 8ig8|12 years ago|reply
http://wordpress.org/news/2013/08/oscar/
[+] [-] uladzislau|12 years ago|reply
[+] [-] ck2|12 years ago|reply
Maybe some wordpress.com blogs were being used for spam but wordpress.com != wordpress.org
[+] [-] sehrope|12 years ago|reply
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
[2]: http://wp.tutsplus.com/articles/insights-into-wp-cron-an-int...
[+] [-] colinsidoti|12 years ago|reply
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.)
[+] [-] oinksoft|12 years ago|reply
[+] [-] toble|12 years ago|reply
I remember doing something similar for a stats script that would wipe old data every time it was viewed by an admin.
[+] [-] chrisguitarguy|12 years ago|reply
> 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.
[+] [-] 8ig8|12 years ago|reply
[+] [-] rmccue|12 years ago|reply
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.
[+] [-] yogo|12 years ago|reply
[+] [-] wodenokoto|12 years ago|reply
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.
[+] [-] jacques_chester|12 years ago|reply
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.
[+] [-] will_work4tears|12 years ago|reply
[+] [-] dbarlett|12 years ago|reply
[+] [-] jboynyc|12 years ago|reply
In all fairness, I think that's because the admin has been playing around with file permissions on the server side. I can't even log in right now to read the errlog.
[+] [-] jacques_chester|12 years ago|reply
[+] [-] hillbillyjack|12 years ago|reply
Just curious whether or not your fear is from a previous experience.
Will you upgrade to new releases day 1 when WordPress implements auto-updating on the security updates?
[+] [-] capex|12 years ago|reply
[+] [-] rmccue|12 years ago|reply
[+] [-] jacques_chester|12 years ago|reply
[+] [-] mattkrea|12 years ago|reply
Thanks for allowing non-technies to set up their own site but no thanks--I'm good.
[+] [-] smcnally|12 years ago|reply
If there's a request for cgi-bin should we throw apache away, too?
[+] [-] rmccue|12 years ago|reply
[+] [-] rabino|12 years ago|reply
[+] [-] toble|12 years ago|reply