5 ms·

Too late for... ?

by Kudos 13y ago

Too late for... ?

jacques_chester 13y ago
For me, at least. I run a small blogging network. Linode have upgraded RAM, added cores, added disk space. They've done everything except improve random-access I/O, which is a major bottleneck for Wordpress installations thanks to MySQL's penchant for joining tables on disk regardless of indices. I moved to DigitalOcean about 8 months ago simply to get access to SSDs. In most other respects I preferred Linode.
- apapli 13y ago
  Hey fellow Australianite. I've been looking at using DO instead of Amazon, the main stumbling block for me is I cannot seem to figure out if they offer any configurable firewal. Ie I want to modify port rules, blocking them mostly. Does DO offer this, and how have you found them so far? My use case is similar to yours - hosting for multiple shopping carts running on MySQL, hence the appeal of SSDs.
  - jacques_chester 13y ago
    I don't think DigitalOcean themselves offer a firewall. You'd need to block ports at your server.
    - matiasb 13y ago
      They don't :(
  - voltagex_ 13y ago
    Another Australianite here. You can just bind to localhost if you don't want things to be open to the world, or modify iptables. Your other issue in Australia is the latency to DO's servers - ~200ms for the US and 350+ for a European droplet. Cloudflare may help there, though.
    - jacques_chester 13y ago
      It's a blog network. Latency matters, but not so much that I can justify paying the ruinous bandwidth rates Australian hosts want. I'd be looking at several hundred extra dollars per month for what is really a quite modest operation.
    - josephb 13y ago
      > Your other issue in Australia is the latency to DO's servers Roughly 160ms from East Coast AU to DO's LA droplets, most of us are used to the extra milliseconds by now :-)
- tiredofcareer 13y ago
  You need a cache in front of Wordpress so that it doesn't hit the database on every read, then you can run Wordpress anywhere. I survived close to 3,000 req/sec against a Wordpress entry using a single Linode 360, back when those were available. wp_supercache, nginx, varnish, etc. Rinse and repeat.
  - jacques_chester 13y ago
    I appreciate the advice, but I knew this already. I've been using WP Supercache since it was released. Nginx for I think 4 years at this point. I have it configured to the point that nginx serves the gzipped pages WPSC writes out to disk without ever hitting PHP. I have three words for you: Recent. Comments. Widget.
    - tiredofcareer 13y ago
      That's why Varnish is more effective, because you can configure it to cache the results of things that WP Supercache misses by design including the Recent Comments Widget and its data. If you need SSDs to run Wordpress, there's a flaw somewhere. Every time I've scaled Wordpress, caching has been the answer. Apply liberally. WP Supercache is a hack anyway, for folks running WP on shared hosts without root. If you have root, there's a plethora of better things for caching, even as ancient as Squid as a reverse. You can get your MySQL traffic down to <1 QPS fairly trivially, no matter what kind of traffic is hitting the frontend. Don't forget wordpress.com is a huge MU installation, and they've existed since before SSDs became popular. The disk is not your issue here.
      - jacques_chester 13y ago
        Varnish is not effective in the face of Recent Comments because that widget breaks whole-page caching fatally. Every time anyone leaves a comment anywhere, the entire cache for the entire site is invalid. When I looked at where the slow runtimes were occurring on Linode, it was always jammed on disk I/O and it was always on PHP functions that are reaching into MySQL. In my experience the MySQL query cache + an object cache do more for sites with a Recent Comments widget than whole page caching. As it happens, I do all of the above. And I was doing all of the above. And still getting jammed on I/O. Because MySQL likes to join on disk. Whole page caching is useful only if you prevent that from happening. It's useless if the cache is rendered invalid every few seconds on a chatty site.

Too late for... ?

by Kudos 13y ago

Too late for... ?

For me, at least. I run a small blogging network. Linode have upgraded RAM, added cores, added disk space. They've done everything except improve random-access I/O, which is a major bottleneck for Wordpress installations thanks to MySQL's penchant for joining tables on disk regardless of indices. I moved to DigitalOcean about 8 months ago simply to get access to SSDs. In most other respects I preferred Linode.

apapli 13y ago
Hey fellow Australianite. I've been looking at using DO instead of Amazon, the main stumbling block for me is I cannot seem to figure out if they offer any configurable firewal. Ie I want to modify port rules, blocking them mostly. Does DO offer this, and how have you found them so far? My use case is similar to yours - hosting for multiple shopping carts running on MySQL, hence the appeal of SSDs.
- jacques_chester 13y ago
  I don't think DigitalOcean themselves offer a firewall. You'd need to block ports at your server.
  - matiasb 13y ago
    They don't :(
- voltagex_ 13y ago
  Another Australianite here. You can just bind to localhost if you don't want things to be open to the world, or modify iptables. Your other issue in Australia is the latency to DO's servers - ~200ms for the US and 350+ for a European droplet. Cloudflare may help there, though.
  - jacques_chester 13y ago
    It's a blog network. Latency matters, but not so much that I can justify paying the ruinous bandwidth rates Australian hosts want. I'd be looking at several hundred extra dollars per month for what is really a quite modest operation.
  - josephb 13y ago
    > Your other issue in Australia is the latency to DO's servers Roughly 160ms from East Coast AU to DO's LA droplets, most of us are used to the extra milliseconds by now :-)
tiredofcareer 13y ago
You need a cache in front of Wordpress so that it doesn't hit the database on every read, then you can run Wordpress anywhere. I survived close to 3,000 req/sec against a Wordpress entry using a single Linode 360, back when those were available. wp_supercache, nginx, varnish, etc. Rinse and repeat.
- jacques_chester 13y ago
  I appreciate the advice, but I knew this already. I've been using WP Supercache since it was released. Nginx for I think 4 years at this point. I have it configured to the point that nginx serves the gzipped pages WPSC writes out to disk without ever hitting PHP. I have three words for you: Recent. Comments. Widget.
  - tiredofcareer 13y ago
    That's why Varnish is more effective, because you can configure it to cache the results of things that WP Supercache misses by design including the Recent Comments Widget and its data. If you need SSDs to run Wordpress, there's a flaw somewhere. Every time I've scaled Wordpress, caching has been the answer. Apply liberally. WP Supercache is a hack anyway, for folks running WP on shared hosts without root. If you have root, there's a plethora of better things for caching, even as ancient as Squid as a reverse. You can get your MySQL traffic down to <1 QPS fairly trivially, no matter what kind of traffic is hitting the frontend. Don't forget wordpress.com is a huge MU installation, and they've existed since before SSDs became popular. The disk is not your issue here.
    - jacques_chester 13y ago
      Varnish is not effective in the face of Recent Comments because that widget breaks whole-page caching fatally. Every time anyone leaves a comment anywhere, the entire cache for the entire site is invalid. When I looked at where the slow runtimes were occurring on Linode, it was always jammed on disk I/O and it was always on PHP functions that are reaching into MySQL. In my experience the MySQL query cache + an object cache do more for sites with a Recent Comments widget than whole page caching. As it happens, I do all of the above. And I was doing all of the above. And still getting jammed on I/O. Because MySQL likes to join on disk. Whole page caching is useful only if you prevent that from happening. It's useless if the cache is rendered invalid every few seconds on a chatty site.