You all know that feeling (well, I hope you do!) that when a spike in traffic occurs on your WordPress site, that the miniature server you have it running on very quickly runs out of resources. Apache’s good like that. Taking up all the resources with its large number of processes consuming oodles of memory each. How on earth can you possibly fix it, especially when you’re running on a tight budget and upgrading the server for that once-in-a-blue-moon you get a spike in traffic? Well, Amazon Cloudfront to the rescue!
If, like us, you’re running a shared hosting platform on Amazon EC2, and have many clients requiring SSL certificates, you’ll probably be using Elastic Load Balancers to do the SSL termination for you, since you can’t have multiple Elastic IP’s associated with a single instance.
However, when you reach either 5 or 10 ELB’s, you’ll be greeted with this error message when trying to create another one:
Error: TooManyLoadBalancers: undefined
Amazon define relatively low quotas for new AWS accounts, which are usually fine for most users. However, some use cases apply where you need these limits to be increased. The problem with the ELB limit, is that there’s not very much documentation explaining that there is a limit, nor how to request to increase it. The answer lies hidden away here on Amazon’s AWS site. This is the form you need to fill in to request an increase on the account’s ELB limit.
I realise that I’ve been neglecting my blog for a while now, with my last post published at the end of March. Quite frankly, I’ve not had anything interesting to write about. However, career starting pastures new, I’m starting to have interesting things to write about again. Over the course of time, I’ll probably post a lot of stuff about Amazon Web Services (AWS), Zend Framework, amongst other things. Today’s babble though is about implementing AWS as your core hosting infrastructure, and the benefits and downsides to it. I’ll also post my findings about the best way (in my opinion) to implement certain requirements.
Announcing the release of the Amazon S3 v2.1 module for Gallery 3. A few changes are presented here;
- Firstly, started using double digits for version numbers so I can create minor revisions
- Added fields to database to store MD5 hashes of files. These are used to match the MD5 hash of the local file, and what the module thinks is uploaded, and also for comparison with S3 itself (which provides an MD5 hash when asked for bucket info)
- Re-visited re-sync task. Taken out “emptying bucket” code (as there’s really no need it seems), and simplified the whole process, allowing the module to compare the MD5 hash of the local file against the same file path on S3, and upload/overwrite if they’re different, or if the module doesn’t believe the file has been uploaded.
- Resolved issues of moving entire albums from one location to another and files disappearing. This invoked a re-visit of the move code as well and cleaned up quite a lot of unnecessary stuff.
Note: I will no longer be updating the gallery3-contrib git repository as it’s just easier to update my site than it is to update a load of other places and wait for pulls to be granted. Sorry.
Well, after a few weeks of having this module used by many in the community as a beta module, and due to lack of bug reports since, I’m now convinced it’s stable enough to release. So, here it is.Amazon S3 for Gallery 3 : v2.1 (md5: )
As always, direct comments, feedback and bug reports to the module’s official thread on Gallery’s forums.
That is all