scottayy wrote:
You might guess a few of the problems correctly, and you might even beat them to the punch. But I can almost guarantee that if you get this high volume traffic, you will find new situations that you didn't think of. A code you suspected of being optimized really may just be slowing things down.
You can go with your own theory

But my theory is it ain't broke till it's broke. Then you fix it. I don't like guessing, so I'm not about to guess about a particular problem. I'll wait till it's fact.
The point is that you dont have to guess, if you've managed to create a site with a performance problem that hasnt already been discussed 1000's of times in the various communications mediums then I take my hat off to you. Forewarned is Forearmed and all that.
Things like good indexing and caching arent "Premature optimisation", they are best practice. As someone else said, experience is the key here and waiting for (scaling) problems to arise (which implies bad design), is wrong on a number of levels. Waiting for the problem to arise before taking preventative action is like treating the symptoms but not the disease.
To the original poster, in terms of scalability personally I take a high estimate of my load/bwidth, add 50% percent and design to that. But even then im not thinking to myself "Right, im never going to imagine anything more. That figure is the highest it will ever be.")
Serious scalability is as much a matter of design as it is of implementation, and as im sure all developers know fixing a broken design after its been deployed and without affecting users is hard.
Also the type of design you create should be based on the expected use of the site, so a forum should be using partitioned tables or the equivalent, a blog should be using static caching (html generated from the db once, and then cached) etc...
If your asking how indexes work, then I suggest you take another look at your db schema, and possibly buy a book about your choice of rdbms. Indexes are a vital component in good scalability, every table should have an indexed primary key at least, and any commonly searched, filtered or sorted field should have an index.
Caching is generally best handled by your framework (php in this case) and sometimes also at the db tier. Its possible to roll your own caching routines using xml(or even csv, lol) as a static intemediary, but its not recommended. No point re-inventing the wheel.
OOP is your friend. Creating a good oop structure will allow you to optimise problem areas without affecting the rest of the app. As long as the interfaces stay the same the code inside can be gutted and rewritten with zero dependency issues (unit testing helps here). Again this requires good design, and is not easy to do right, but the benefit is substantial.
As someone else said, be prepared to throw your first version away, always. You will learn more about the problems by working through them than can ever be obtained by just thinking about it. The second version you write will be far superior by way of foreknowledge and practice, and its often quicker to rewrite than to refactor.
So I should just release my website as is (without any prior modifications) to the public and only try to fix it when the public complains?
Yes and no. There comes a point where you have to say ok, I've done enough here, its not perfect, but its close enough that any further modifications will be reconfiguring existing code/schema and not replacing them in situ. Exactly where this point is, again, comes from experience. Always design and implement with performance in mind, its a lot easier in the long run.