3 ms·

If it's low traffic enough and the footprint is small, couldn't the whole thing be thrown in a couple S3 buckets? I'm still learning this stuff.

neurostimulant 7y ago
I don't think you can run PHP off an S3 bucket. You certainly can sync the upload folder (static files) to S3 as a form of CDN via some 3rd party plugins, but it doesn't solve the main issue when you try to run wordpress in multiple instances load-balanced setup (I assume the diagram is intended to address this, hence the complexity). For low traffic sites, you probably won't need to worry about this yet. The real headache is when you need a load-balanced setup. You'll need to keep the whole wordpress directory (not just the upload directory) synced between instances, which you can't do over S3. NFS is a popular option, but NFS server usually have a hard limit on the number of connected clients, which ultimately limit the number of your instances (e.g. if you need 20 instances but your NFS server crap out when >12 clients connected, you're out of luck). Amazon EFS supposed to solve this since it supports up to 1000 connected clients, but people often complain about slow performance. That being said, scaling wordpress to handle high traffic is a headache unless you write your own theme and plugins. The majority of wordpress sites use those visual editor plugins and mega themes, which is a nightmare when you hit by high traffic as they are often impossible to cache (crazy stuff such as css/ generator that vary its output depending on user agents, etc) and often rely on wordpress statefulness (write arbitrary files to arbitrary locations, which means typical load-balanced/autoscaling architecture will not work as it assume your application is stateless). Personally, I'd rather rewrite the whole site with something else than trying to setup a load-balanced wordpress installation.

neurostimulant 7y ago

I don't think you can run PHP off an S3 bucket. You certainly can sync the upload folder (static files) to S3 as a form of CDN via some 3rd party plugins, but it doesn't solve the main issue when you try to run wordpress in multiple instances load-balanced setup (I assume the diagram is intended to address this, hence the complexity). For low traffic sites, you probably won't need to worry about this yet. The real headache is when you need a load-balanced setup. You'll need to keep the whole wordpress directory (not just the upload directory) synced between instances, which you can't do over S3. NFS is a popular option, but NFS server usually have a hard limit on the number of connected clients, which ultimately limit the number of your instances (e.g. if you need 20 instances but your NFS server crap out when >12 clients connected, you're out of luck). Amazon EFS supposed to solve this since it supports up to 1000 connected clients, but people often complain about slow performance. That being said, scaling wordpress to handle high traffic is a headache unless you write your own theme and plugins. The majority of wordpress sites use those visual editor plugins and mega themes, which is a nightmare when you hit by high traffic as they are often impossible to cache (crazy stuff such as css/ generator that vary its output depending on user agents, etc) and often rely on wordpress statefulness (write arbitrary files to arbitrary locations, which means typical load-balanced/autoscaling architecture will not work as it assume your application is stateless). Personally, I'd rather rewrite the whole site with something else than trying to setup a load-balanced wordpress installation.