Site performance issues


in Geek stuff, Internet matters

I am aware that site performance here is less than ideal in at least three ways:

  • Sometimes pages are simply slow to load
  • Pages that do exist sometimes fail to load entirely, producing a 404 error instead
  • Sometimes, pages load without images or CSS, showing only text

It’s much worse on the administrative side, with frequent page load errors and constant problems with image file uploads.

This site is WordPress-based, which means it uses PHP and a MySQL database. Instead of generating each page dynamically every time it is requested, it uses WP SuperCache, and I have tried experimenting with the plugins various settings, so far without fully resolving the problems.

The site is hosted on DreamHost’s standard, approximately $100/year unlimited storage / unlimited bandwidth shared hosting plan. It would be possible to upgrade to a virtual private server, but it’s significantly more expensive and offers rather limited storage (only 30GB for the cheapest plan).

I will work on trying to diagnose exactly what’s causing these speed and reliability problems. If WP-savvy people have any suggestions, I’d be happy to hear them.

{ 4 comments… read them below or add one }

Milan July 22, 2017 at 9:33 pm

WordPress hosting plans from WPengine have the same unwelcome combination of a much higher monthly cost and tiny amounts of storage space.

. July 22, 2017 at 9:34 pm

I have my own Wordpress blog (hosted on Dreamhost) that’s been driving me nuts. Intermittently I get a 404 error when posting or when moving through the admin pages. Simply reloading usually brings up the page. My Wordpress is up to date and so are my plugins. Besides the usual “disable all plugins and re-enable one-by-one” what other debug can I do?

. July 26, 2017 at 11:26 am

i was having problems all day with what seemed to be 404 misfirings.

anyway, i just finished chatting with a dreamhost tech support person who told me that a user account i have with them was hitting process memory resource limits (all processes) and that was what was causing strange, seemingly htaccess-related problems. i was getting intermittent 404 errors from an htaccess file that should not have been called at all! it was dreamhost with a haunted house server.

apparently, the process killing robot that dreamhost uses will kill a web process in the middle and then for some reason, the (now zombie) apache actually tries to finish its job (doing its best to exit cleanly out of the unglamorous end to a subrequest is my best guess). it throws a 500 error into the main http log, but after doing so, it actually fires off the rewrite condition and rule that should never have been fired (using the standard file -f and directory -d htaccess file above) – and it doesn’t write a new log entry! a new (invisible man) request then triggers the index file in the last line of the htaccess file

beware the resource limits in dreamhost basic accounts! if you go over their limits, and you have htacess with mod_rewrite lines you will see strange things that are only fit for halloween night – invisible men, haunted 404s! undead processes! zombie apache! htaccess moving on its own! yikes!

hope this helps you avoid some hours of pain.

. July 26, 2017 at 11:28 am

I can only relate my own experience, and so far, I have not found a “definite” rule to fix all issues at one stroke.

The major problem with DreamHost’s setup is that, in the eternal fight to keep memory consumption at a minimum, it means getting rid of as many features as possible — namely, all that will reduce bandwidth (good for the visitors!) or CPU (good for the server, but DreamHost doesn’t control CPU consumption as aggressively as they control RAM). For instance, this means getting rid of gzip’ed HTML + CSS (which will consume CPU + RAM) or any of the several Minify plugins (which will consume RAM as well). The more sophisticated the cache (I’m fond of using W3 Total Cache, or at least WP Super Cache), the more RAM will be consumed as well.

Similarly, many plugins which limit the number of MySQL queries to improve performance will instead consume RAM. So finding a trade-off where you can still keep your site replying with good performance while avoiding to consume precious RAM is a hard task!

So far, my best results on busy sites is to uncheck Page Speed Optimization and Extra Web Security which will apparently consume a lot of RAM, and rely instead on a combination with W3 Total Cache and Cloudflare (free reverse proxy service). Cloudflare will effectively do the same thing as the “Extra Web Security” module, but since it runs outside DreamHost, it’s fine. W3 Total Cache consumes a lot of memory but once the pages are statically stored locally, Cloudflare will very efficiently cache them — so you might get 404/500 while editing posts, at least your visitors will not experience them (Cloudflare also can serve static pages even if DreamHost gives a 404 or a 500).

Also, thanks to this article, I have found out that FastCGI uses more RAM than ‘normal’ CGI. And since PHP 5.3 is better at managing RAM (more aggressive garbage collection, less memory leaks), I’ve experimentally switched to PHP 5.3 CGI (not FastCGI) without Page Speed Optimization nor Extra Web Security, relying on W3 Total Cache + Cloudflare to accelerate the site. Now the backoffice is slower (more CPU consumption!) but at least I don’t see 404/500 (so far!).

I’m still unhappy with the combination, so I’ll certainly continue to tweak DreamHost’s settings hoping to reduce RAM consuption even more and still get adequate performance. Like @dgw said, I also use a lot of plugins — because I require their functionality. Not everybody hosting WP with DreamHost has simple, blogging needs; the more complex the site, the more functionality it will require… and that’s the beauty of WordPress, you just need to use the plugins you really need, and keep the core WP install simple if you’re happy with few needs. Plugins, however, aren’t necessarily “bad” or that heavy on the site; but it’s true that some may consume a lot of RAM…”

Leave a Comment

Previous post:

Next post: