10 users? You want a $5 DigitalOcean, a $10 Linode, or similar. A single server can handle a lot more than 10. There's a trend on HN obsessed with high availability and scalability that makes it sound like every website needs to be extremely resistant to any failures. The majority of websites need no such thing. If you're spending more than $50/month on a very small website, you are more than over-engineering the requirements.

Thanks. It is on a $10 Linode. But currently uses Amazon Cloudfront to server most assets, which is overkill. It costs like $0.50, but it's the extra engineering complexity that I'd like to avoid.

I agree with you.

Absolutely. Amazon is selling magic beans[0], quite often. They have lots of tools that they convince new engineers are the best. But quite often, if not always, the existing FOSS tools (upon which most of AWS is built and from whence they came) offer superior performance at a far better price point for most scale.

In tribute to the Dead Milkmen, in case you want to sue me, I'm talking about this book - http://www.amazon.com/Magic-Beans-Nutrient-Rich-Disease-Figh...

I think AWS doesn't go for "superior performance at a far better price point for most scale". They go for, our solutions are a click away, and take far less time to setup then rolling your own. You know because engineer costs are the biggest cost component really.

Once your at a large enough scale, then yes engineer costs become a smaller component and becomes worth it.

Correct. But I believe they sell and market it this way. Their best value is for companies that want burstability, convenience and/or have dysfunctional organizations that have slow internal expensive bureaucracy.

If the PHP responses are relatively static, adding a bit of caching in front of it will improve the responsiveness and decrease the load dramatically. Simply adding a 5 minute cache let us scale one PHP application from 100 concurrent to "SSL & gzip require more CPU than PHP". We figured that was sufficient.

More dynamic applications (like a commenting system) might feel better at 10-30 seconds of caching with expiration commands, but it will still help scale up significantly.

By caching, you mean like script execution caching that PHP accelerators give? https://en.wikipedia.org/wiki/List_of_PHP_accelerators

Am I right in thinking that such caching comes built-in with PHP 5.5+ ?

Look at Varnish Cache https://www.varnish-cache.org/ and Google's PageSpeed module on the server. https://developers.google.com/speed/pagespeed/?hl=en

Thanks. That's quite added complexity in my scenario, which I think I would avoid.

Nginx and Apache have built in caching which can usually be easily enabled, which while arguably not as fast as using Varnish (Nginx in particular will serve cached content from disk using sendfile, as opposed to Varnish's in-memory caching) are still faster than calling back into PHP.

PageSpeed is 1 liner installation on your instance. It will compress assets etc automatically as Apache serves them. Worth adding to your deployment script.

Nice. I like how it could be installed in Apache, and then left to its own devices.

"users" is a bad metric. How many requests are you getting?

You can run wordpress (a fairly unoptimized app) on a tiny linux VM and easily serve 50 requests per second. That's 4M requests over 24 hours.

If you need more than that, just upscale your server. 1 midsize server these days can handle 100M requests per day without a problem if it's just running a basic site.

Would you bother with CDN delivery for Wordpress at 50 requests per second? It would speed up delivery for users, but I suspect it passes my level off "too complex for current situation".

I believe it's still worth it. Using a CDN will definitely help speed up the delivery of your static assets especially to those who are further away from your origin server. They're also quite simple to set up as there are many Wordpress plugins out there that allow you to simply enter your CDN url which will rewrite your current static asset URLs (e.g. CDN Enabler).

Using a pay-as-you-go CDN service would likely be the way you would want to go just so that you aren't tied down to any monthly commitment that you may not end up fully using.

I would suggest taking a look at KeyCDN (https://www.keycdn.com/) which is quite affordable.

Depends on how much you care about your users but yes, I would.

CDN's are very cheap and easy to setup. No big contracts or commitments these days. You can use them just for the static assets or for your entire site to make it faster for everyone while also reducing requests to your origin server.

MaxCDN is cheap and effective or you can use CloudFlare and get their security features too and not worry about bandwidth.