6 ms·
I've configured my web application to deploy to S3/Cloudfront for asset deployment. It's a PHP app. In the end, I might just pay a little more for a faster ser
by miseg 11y ago
I've configured my web application to deploy to S3/Cloudfront for asset deployment. It's a PHP app.
In the end, I might just pay a little more for a faster server. Keep things simple, everthing on the one app.
It's a "normal" app (in the grand scheme of the Internet), so 10 users at a time would be high traffic already.
- falcolas 11y agoIf 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.
- miseg 11y agoBy caching, you mean like script execution caching that PHP accelerators give? https://en.wikipedia.org/wiki/List_of_PHP_accelerators https://en.wikipedia.org/wiki/List_of_PHP_accelerators Am I right in thinking that such caching comes built-in with PHP 5.5+ ?
- semerda 11y agoLook at Varnish Cache https://www.varnish-cache.org/ https://www.varnish-cache.org/ and Google's PageSpeed module on the server. https://developers.google.com/speed/pagespeed/?hl=en https://developers.google.com/speed/pagespeed/?hl=en
- miseg 11y agoThanks. That's quite added complexity in my scenario, which I think I would avoid.
- falcolas 11y agoNginx 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.
- semerda 11y agoPageSpeed is 1 liner installation on your instance. It will compress assets etc automatically as Apache serves them. Worth adding to your deployment script.
- miseg 11y agoNice. I like how it could be installed in Apache, and then left to its own devices.
- late2part 11y agoAbsolutely. 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-Fighting-Powerhouse/dp/0471347477 http://www.amazon.com/Magic-Beans-Nutrient-Rich-Disease-Figh...
- UK-AL 11y agoI 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.
- late2part 11y agoCorrect. 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.
- developer2 11y ago10 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.
- miseg 11y agoThanks. 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.
- manigandham 11y ago"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.
- miseg 11y agoWould 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".
- manigandham 11y agoDepends 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.
- CodyA 11y agoI 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/ https://www.keycdn.com/) which is quite affordable.