Current time: 04-23-2014, 08:51 PM Hello There, Guest! (LoginRegister)

404 on wordpress
05-31-2011, 10:24 AM
Post: #1
404 on wordpress
getting random 404 errors, and a refresh page brings up the actual page
thanks
Find all posts by this user
05-31-2011, 09:30 PM
Post: #2
RE: 404 on wordpress
if you want help, you might want to provide a few more details. Check the log files and post any details, link to the site, any .htaccess mods you've made, etc etc...
Find all posts by this user
09-11-2011, 02:33 PM
Post: #3
RE: 404 on wordpress
While this thread is a bit old, I hope I might help out...

Recently, most (if not all) my WordPress sites have randomly been given 404 (and sometimes 500) errors. The amount of plugins, traffic, etc. seems to be irrelevant, but things get worse during PST prime time. This was tracked down to heavy RAM consumption: since DreamHost is in the business of selling their VPS solution — where you can reserve a certain amount of RAM — they're very aggressive in making sure "normal" users don't use too much RAM.

The way this works is like this: watchdog processes run in the background and aggressively kill all processes that are consuming too much RAM. "Too much RAM" is not easy to define: in my experience, it can be as little as 256 MB or so. Now most WordPress processes will consume that amount easily.

Why? Well, DreamHost has launched a few new cool features. For instance, you can use PHP 5.3 in FastCGI mode, which will be much faster and use less CPU — improving not only your site's performance but also being less heavy on the shared server, so everybody benefits. We can now use Google's Page Speed optimisation module, which will compress pages and do some extra magic in order to make download times shorter — saving bandwidth (also great for the shared environment) and even adding some extra performance as well. And finally, for the security-conscious, DreamHost has allowed us to enable Apache's mod_security module, which deals with attacks to your site.

Sadly, all these consume memory. A lot of memory. The tradeoff for being lighter on the CPU, saving bandwidth, and increasing performance and security is — more RAM. So even a bare bones install of WordPress with all those options on will sadly consume more RAM than DreamHost's watchdogs allow. :-(

Many have suggested diminishing the number of plugins, or replacing plugins with some that increase performance, etc. This will sadly even make the matter worse. Some newer plugins try to keep MySQL queries to a minimum and do extra caching to increase performance. By doing so, they consume more RAM. Remember, RAM is very cheap if you're running your own server. But in DreamHost's environment, RAM is at a premium! So replacing plugins with older, less efficient ones, which however will consume less RAM, is actually a good way to prevent those nasty 404/500 errors!

Of course you might then be concerned by the overall performance of your WP site. Well, I can only relate my experience: I'm using W3 Total Cache as my caching plugin. It's tricky to configure, but it's very efficient in creating not only static pages of your whole site, but also to aggressively force browsers to cache as much as possible! And to get a boost in performance, I recommend using Cloudflare, which is a (free) external cache/proxy/content deployment network. I get only 40-60% of the requests when using Cloudflare (the rest is served directly by it) and W3 Total Cache integrates with Cloudflare neatly. Not only that, but Cloudflare also checks for security attacks, incoming connections from known spammers, and so forth. So effectively the RAM-consuming options that DreamHost gives us on the control panel are neatly replaced by the combination of W3 Total Cache and Cloudflare!

Of course, your backoffice will be slow. But that is irrelevant: slow is fine, so long as you don't get 404/500; and what ultimately matters is how well visitors can see your site. Since they will mostly get content from Cloudflare or cached content from W3 Total Cache, this should could give you extra performance without the RAM penalty.

I'm posting it here because these random 404 errors have driven me crazy for half a year... hopefully these tips also help you out as well!

I'm just a virtual girl in a virtual world...

Take a look at my blog on virtual worlds
Visit this user's website Find all posts by this user
09-11-2011, 06:07 PM
Post: #4
RE: 404 on wordpress
(09-11-2011 02:33 PM)Gwyneth Llewelyn Wrote:  I'm posting it here because these random 404 errors have driven me crazy for half a year... hopefully these tips also help you out as well!

Thanks for sharing. I think what we need to do, though, is to compare some hard facts. If I get time later, I'll set up a table in the wiki where we can all share detailed notes. Some of the critical data we need are:
  • average successful page requests per day
  • maximum concurrent requests during your site's prime time
  • maximum errors during the above
  • average unsuccessful page requests per day
  • total memory consumption as reported at the bottom of the WP dashboard
  • PHP memory limit settings (in case you have a custom php.ini, otherwise I think the default is set to 90MB)
  • caching measures taken
  • report of site performance from a service such as loadimpact.com
  • link to actual site
Without details such as these, there's no way to compare across people's experiences. For what it's worth, I don't run WP on my most popular site. I run an app built on a custom framework which is designed to be as efficient as possible, and if DH support is to be believed, they have never killed any processes due to memory issues. I contacted them after the site got posted on Reddit which lead to sustained activity for 24 hours or so but the site performed fine.

Just for comparison, on that day, my site saw approximately 1 new unique visitor per minute for 24 hours. Each visitor made, on average, approximately 70-100 successful page requests. 95-99% of those requests are in the form of an AJAX call answered with 5-10k of JSON-encoded HTML and JS. My resource logs from that day report that the average, min, and max consumed memory was 16,592k, 949k 54,304k, respectively. So that's probably well within the memory limits of shared hosting which seems to unofficially be about 90MB (although DH won't confirm this, it's not hard to run a few tests to see when your processes are killed due to high memory).
Find all posts by this user


Forum Jump: