It’s been some time since I wrote here; we’ve had a few setbacks with our chosen name. We were told we’d be facing some trademark litigation if we went forward with it, so dropping that premium domain name, finding the courage to spend money on another premium domain name again was a fairly taxing ordeal.
Now we have a name that’s been cleared of any obvious patent/trademark litigation issues, we’re waiting on the actual domain transfer to our registrar.
Some new things I’m using this month are Trello from FogCreek, a simple (*agile*, but I don’t use it for that purpose) list-making/organising board. I highly recommend it. The stack behind it is also very contemporary; compared to FogCreek’s other software, Trello is on the cutting edge. LESS for CSS, CoffeeScript for their JS along with backbone.js. You can read more on that at fogcreek: http://blog.fogcreek.com/the-trello-tech-stack/
Amazon Web Services RDS (Relational Database Service) – so here what Amazon does is take care of the install, maintenance, regular backup/snapshot, and master-slave configuration for your database over multiple availability zones and give you a single price to pay, a single endpoint to connect to, advanced and flexible security, and lots of metrics to follow the performance of your DB.
I’m extremely pleased with RDS for now. I understand there can be some write latency due to the concurrent/consistent-write nature of their master/slave setup. But off the bat I know my DBs are safe, at least against the most common failures. Some write latency for that peace-of-mind is a worthy tradeoff.
nginx: best thing since slices of virtual machines
nginx: this one I’ve taken up very recently, but I’m extremely pleased with its low-overhead nature. Having to struggle with apache’s memory demands, in todays RAM-based-pricing market was a constant occupation.
When switching over to nginx its not just about replacing Apache but replacing mod_php as well. Running PHP as an external daemon has been a new experience, and not without some segfault madness. But its also refreshing to have it as an external resource, completely separate yet supported by nginx’s internals. Some of the problems I had to troubleshoot have been very unpopular, I’ve been frustrated with Google a couple of times for making me go in circles, giving too much weight to a single keyword. Sometimes I wished Google would just say ‘Hey buddy, I got nothing for you on this one.’ rather than making me have to go through pages of irrelevant content.
Outdated Xeon CPUs are recipe for underperforming nginx setups
During our trial and error phase we learned a couple of things. The most shocking was this: AWS will give you old generation Xeon CPUs on their low/mid-end instances. Always check ‘cat /proc/cpuinfo’ to see what generation Xeon you’re using. Apparently the instruction set has seriously been expanded and improved upon, and furthermore modern CPU-focused software like nginx are highly capable of utilizing on those new instruction sets so you’re losing a lot of performance between even a single generation of CPUs.
BTW, Linode’s cheapest VPS has an L55xx Xeon, as always – kudos Linode!
I’ve had to open a few tickets recently, and I didn’t even know this but Linode’s support is stellar people. 10 out of 10, easily. Average response time has been 5-6 minutes and very professional.