shh
one of the secrets of doing things on the web is how little hardware and clever coding you really need. www.mysql.com is a dual p3/850 serving over 16 million page views per month.
the coding is quite ham-handed for the most part, honestly.
here’s how ham-handed: except for the documentation pages, all of the .html
pages are handled via a php script that creates an output buffer, includes the file, captures the output buffer into a variable, outputs the header (which gets things like the page title from a variable that were set when the file was included), outputs the data, and then outputs the footer. (the documentation pages are actually php files that include calls to generate the header and footer.) require_once
all over the place. a three-element include_path
. no Last-Modified
header (or conditional GET
handling, obviously). no php compiler cache. 96 RewriteRule
. the news on the front page? pulled from the database on every hit. (the query cache is turned on, however.)
things do gradually improve. i finally nuked the include file that had gems like this one:
function open_tr() { echo("<tr>"); }
i’ve also finally pared things down so the list of country names is only in one common include file. (actually, that’s not quite true. there are some old forms that define it on their own. one of them has three copies. and the geoip code has its own copy.)
maybe this isn’t the best time to mention i’ll be giving a best practices talk at the 2004 mysql users conference.
Comments
Add a comment
Sorry, comments on this post are closed.
Even with all the opportunities for improvement listed above, I bet that installing a compiler cache will get you 95% of return with only 5% of the effort. And from the benchmarks I've seen, it really doesn't matter which one you choose, either.