superdupler wrote:
so linode caps out on 5,000 concurrent connections?
The basic
NodeBalancer plan caps out at 5,000 concurrent connections. However, there's no hard connection limit on a Linode, but the kernel and your applications might have limits.
Quote:
what do you mean by well-designed indexes and queries?
You typically query a database using SQL, and how the query is designed can drastically change the amount of time it takes to run. Most SQL databases also support indexes, which are somewhat like the index in the back of a book: instead of scanning through an entire book looking for the word 'gazpacho', an index tells the database that the word 'gazpacho' appears in a specific place.
Query design and indexing and SQL server tuning are an art, and they are quite application-specific. They're also the sort of thing that you don't want to optimize prematurely: it doesn't make much sense to shave 50 milliseconds off of a query that, as it turns out, only happens twice a day.
Quote:
does 'a layer of caching' means caching queries?
Or the results from them, at least. If you have queries like SELECT `content` FROM `articles` WHERE slug = 'slug-futures-skyrocket', you can save your database some work by using something like memcached to store the results for quick retrieval later on. Most decent frameworks handle this for you; there's a few rather interesting problems.
Another thing I forgot to mention originally: if you have two application servers and one of them dies, you're OK, because you have a second one. If you have one database server and
it dies, you're SOL until it comes back. So, be aware that it's not a high-availability setup, just a load-balancing one.

_________________
Code:
/* TODO: need to add signature to posts */