1. Define the scalability goals for your application. If you don’t know how many requests you’re shooting for, you don’t know whether you’ve built something that works, and how long it’s going to last you.
2. Measure everything. CPU usage, memory usage, disk I/O, network I/O, requests per second, with the last one being the most important. If you don’t know the baseline, you don’t know whether you’ve improved.
3. Design your database with scalability in mind. Assume you’ll have to implement replication.
4. Do not rely on NFS for code sharing on a server farm. It’s slow and it’s got locking issues. While the idea of keeping one copy of code, and letting the rest of the servers load them via NFS might seem very convenient, it doesn’t work in practice. Stick to some tried practices like rsync. Keep the code local to the machine serving it, even if it means a longer push process.
5. Play around with I/O buffers. If you’ve got tons of memory, play with TCP buffer size – your defaults are likely to be set conservatively. See your tax dollars at work and use this Linux TCP Tuning guide. If your site is written in PHP, use output buffering functions.
6. Use Ram Disks for any data that’s disposable. But you do need a lot of available RAM lying around.
7. Optimize bandwidth consumption by enabling compression via mod_deflate, setting zlib.put_compression value to true for PHP sites, or Tidy content reduction for PHP+Tidy sites.
8. Confugure PHP for speed. Turn off the following: register_globals, auto_globals_jit, magic_quotes_gpc, expose_php, register_argc_argv, always_populate_raw_post_data, session.use_trans_sid, session.auto_start. Set session.gc_divisor to 10,000, output_buffering to 4096, in John’s example.
9. Do not use blocking I/O, such as reading another remote page via curl. Make all the calls non-blocking, otherwise the wait is something you can’t really optimize against. Rely on background scripts to pull down the data necessary for processing the request.
10. Don’t underestimate caching. If a page is cached for 5 minutes, and you get even 10 requests per second for a given page, that’s 3,000 requests your database doesn’t have to process.
11. Consider PHP op-code cache. This will be available to you off-the-shelf with PHP6.
12. For content sites consider taking static stuff out of dynamic context. Let’s say you run a content site, where the article content remains the same, while the rest of the page is personalized for each user, as it has My Articles section, and so on. Instead of getting everything dynamically from the DB, consider generating yet another PHP file on the first request, where the article text would be stored in raw HTML, and dynamic data pulled for logged-in users. This way the generated PHP file will only pull out the data that’s actually dynamic.
13. Pay great attention to database design. Learn indexes and know how to use them properly. InnoDB outperforms MyISAM in almost all contexts, but doesn’t do full-text searching. (Use sphinx if your search needs get out of control.)
14. Design PHP applications in an abstract way, so that the app never needs to know the IP address of the MySQL server. Something like ‘mysql-writer-db’, and ‘mysql-reader-db’ will be perfectly ok for a PHP app.
15. Run external scripts monitoring the system health. Have the scripts change the HOSTS if things get out of control.
16. Do not do database connectivity decision-making in PHP. Don’t spend time doing fallbacks if your primary DB is down. Consider running MySQL Proxy for simplifying DB connectivity issues.
17. For super-fast reads consider SQLite.  But don’t forget that it’s horrible with writes.
18. Use Keepalive properly. Use it when both static and dynamic files are served off the same server, and you can control the timeouts, so that a bunch of Keep-alive requests don’t overwhelm your system. John’s rule? No Keep-alive request should last more than 10 seconds.
19. Monitor via familiar Linux commands. Such as iostat and vmstat. The iostat command is used for monitoring system input/output device loading by observing the time the devices are active in relation to their average transfer rates. The iostat command generates reports that can be used to change system configuration to better balance the input/output load between physical disks. vmstat  reports  information about processes, memory, paging, block IO, traps, and cpu activity.
20. Make sure you’re logging relevant information right away. Otherwise debugging issues is going to get tricky.
21. Prioritize your optimizations. Optimization by 50% of the code that runs on 2% of the pages will result in 1% total improvement. Optimizing 10% of the code that runs on 80% of the pages results in 8% overall improvement.
22. Use profilers. They draw pretty graphs, they’re generally easy to use.
23. Keep track of your system performance. Keep a spreadsheet of some common stats you’re tracking, so that you can authoritatively say how much of performance gain you got by getting a faster CPU, installing extra RAM, or upgrading your Linux kernel.

Complete presentation is down below:

| View | Upload your own

1. A drop of 100ms in page rendering time leads to 10% in sales on Amazon. A drop of 500 ms leads to 20% less traffic to Google.
2. Make fewer HTTP requests – combine CSS and JS files into single downloads. Minify both JS and CSS.
3. Combine images into CSS sprites.
4. Bring static content closer to the users. That usually means CDNs like Akamai or Limelight, but sometimes a co-location facility or data center in a foreign country is the only option.
5. Static content should have Expires: headers way into the future, so that they’re never re-requested.
6. Dynamic content should have Cache Control: header.
7. Offer content gzip’ed.
8. Stoyan claims nothing will be rendered in the browser till the last piece of CSS has been served, and therefore it’s critical to send CSS as early in the process as possible. I happen to have a document with CSS declared at the very end, and disagree with this statement – at least the content seems to render OK without CSS, and then self-corrects when CSS finally loads.
9. Move the scripts all the way to the bottom to avoid the download block – Stoyan’s example shows placing the javascript includes right before </body> and </html>, although it’s possible to place them even further down (well, you’d break XHTML purity, I suppose, if you declare your documents to be XHTML).
10. Avoid CSS expressions.
11. Consider placing the minified CSS and JS files on separate servers to fight browser’s default pipelining settings – not everybody has FasterFox or tweaked pipeline settings.
12. For super-popular pages consider inlining JS for fewer HTTP requests.
13. Even though placing content on external servers with different domains will help you with HTTP pipelining, don’t go crazy with various domains – they all require DNS lookups.
14. Every 301 redirect is a wasted HTTP request.
15. For busy backend servers consider PHP’s flush().
16. Use GET over POST any time you have a choice.
17. Analyze your cookies – large number of them could substantially increase the number of TCP packets.
18. For faster JavaScript and DOM parsing, reduce the number of DOM elements.
19. document.getElementByTagName(‘*’).length will give you the number of total elements. Look at those abusive <div>s.
20. Any missing JS file is a significant performance penalty – the browser will browse the 404 page you generate, trying to see if it has valid <script>s.
21. Optimize your PNGs – check out pngcrush, pngoptimizer
22. Optimize JPEGs – jpegtran
23. Make sure you have favicon.ico – generating those 404s will be expensive, plus once you have it, it’s cache-able.
24. Toolkits for measuring page loads: AOL PageTest, FiddlerTool HTTP debugging proxy, IBM Page Detailer instrumentation tool, YSlow, and Firebug are suggested in the presentation. My personal addition to the list is Charles that has been recommended by a colleague.

And here’s the whole presentation, although it’s not possible to follow links from Slideshare slides.

IBM DeveloperWorks introduces us to XCache on PHP:

XCache is a relative newcomer, but many sites are reporting good results with it. In addition, it is easy to build, install, and configure because it’s implemented as a PHP extension. Recompiling Apache and PHP isn’t required. This article is based on XCache V1.2.0. It reliably supports PHP V4.3.11 to V4.4.4, PHP V5.1.x to V5.2.x, and early versions of PHP V6. (XCache doesn’t support PHP V5.0.x.) XCache works with mod_php and FastCGI, but not with the Common Gateway Interface (CGI) or the command-line PHP interpreter. The XCache source code builds on a variety of systems, including FreeBSD, Sun Solaris, Linux®, and (as shown here) on Mac OS X. XCache can be built on Microsoft® Windows®, as well, using the Cygwin UNIX® emulation environment or Visual C. You can build XCache for Cygwin or for native Win32. The latter target is compatible with the official Win32 release of PHP.

You use the Auth package to authenticate users in your site. Out of the box, it supports many different ways of authenticating users, including storage in a database, in files, or even by using SOAP calls. You can even write a custom container object that allows you to write your own method to authenticate users.

Donald McArthur over at NewsForge creates a generic reusable PHP calendar template that could be used on any site requiring inputting dates:

My design goals were to create a PHP page that would take as input a querystring value in the form of a Unix epoch number that would represent the beginning moment of a particular date. (I chose the Unix epoch number, which represents the number of seconds that have transpired since the start of January 1, 1970, as that was the data my database SQL statement used as a SELECT criteria.) The script would determine the month and year of that value, and create an array holding a Unix epoch number for the beginning moment for each day in that month. The script would then output HTML to display a calendar, with each date a hyperlink back to the original PHP page, with the associated querystring value for that date.

PHP has two functions which should be your best friends: var_dump and print_r. Both do the same thing: they print out information about a variable in a human-readable form. Some people prefer var_dump, others print_r. Try both and see which one makes more sense to you, it’s more a personal taste.

Not only connects are expensive but you also may run into the trouble establishing number of connections you need. The problem is there can be only so many connections active between Host “Apache” and Host “MySQL”: Port 3306 as connection in TCP/IP protocol is identified by pair of IP addresses and pair of ports (local port and remote port). Yes if you’re establishing thousands of connections per second you normally do not keep it open for long time, but Operation System does. According to TCP/IP protocol Ports can’t be recycled instantly and have to spend some time in “FIN” stage waiting before they can be recycled.

According to Bell’s law, every decade a new class of computer emerges from a hundredfold drop in the price of processing power. As we approach a billionth of a cent per byte of storage, and pennies per gigabit per second of bandwidth, what kind of machine labors to be born? How will we feed it? How will it be tamed? And how soon will it, in its inevitable turn, become a dinosaur?

Nicholas Carr published a lengthy entry contemplating the consequences of this turn in computing:

In arguing that computing is “almost free,” while at the same time describing how costly it actually is, Gilder overlooks the paradox of abundance: that providing a resource in the quantities required to make it seem “free” can be a very expensive undertaking.

Now on to my feelings about this:

The fascination with the large data centers seems to come and go away every few years. You can just look at the Level 3 Communications chart to differentiate the period of enamourment with the technology followed by the period of disappointment. Server farms and giant data centers are cool to talk about, but in reality they provide only marginal advantage – you save on new server racks, when the data center companies are charging extra due to the boom times. With enough capital and commitment anyone can replicate a large data center, and if the business required, it wouldn’t take too much for someone decidedly uncool like Time Warner or News Corp. to invest another billion in a data center of their own, where “thousands and thousands” of servers would provide for a great background for executive photo shoots.

The argument on owning the vital piece of the architecture is important, as your growth shouldn’t be potentially bound by what Hurricane Electric or Equinox decide to charge. However, such architecture, as the aforementioned Level 3 stock chart displays, can be a liability at times when the market is undergoing a downturn, and a Web company finds itself in the business of renting out the server racks to justify the costs of building a data center.

Glider’s Wired article seems to glorify the fact that Google, Yahoo! and Microsoft are all building in Pacific Northwest. That’s Dalles, OR, Wenatchee, WA and Quincy, WA. All located relatively closely to one another and in proximity to major dams, which allow for cheap electricity. So the “cloudware” will work great when I launch a YouTube clone, which will happen to hit big in broadband-wealthy Korea, right? Eeh, so that’s a problem as well. International traffic accounts for huge portions of growth at Google, Yahoo! and Microsoft. In fact, when you look at Comscore numbers for US traffic in September 2006 and Comscore numbers for August 2006 in the United States, you will notice an interesting trend as far as total Internet users – the number of unique US Internet users fell from August 2006 to September 2006. Granted, there’re a few statistical issues here and there, and who knows how ComScore arrives at the exact numbers, so the US traffic might have even grown, but the fact is – US Internet usage growth is pretty much at its plateau right now. The growth for Internet’s top tier is going to come from China, India, Brazil and other emerging markets, and surprisingly the ping times to those places are not too great from either one of Pacific Northwest data centers.

It was pointed out to me, however, that both count and sizeof always need to conduct the pointer arithmetics, even if the array in question is of zero size. Checking for the existence of the first element of the array, however, would involve no pointer arithmetics, since referencing $array[0] is the same as referencing $array pointer. But how much faster is it? I set out to test it with a pretty simple script that would run both comparisons a million times. Since accessing the first element of an empty array would generate a PHP notice (note that it’s not an error, the pointer is still valid), I had to revert to error_reporting(0) at the beginning of the file to exclude the time spent on printing out PHP notices.

It’s also useful to know that whenever the if statement contains a clause that doesn’t have executable code, it will be optimized by the interpreter, and therefore something should be done inside the if() clause once we’re there. So how about running a counter from 1 to a million, checking for the same array over and over, and printing the counter value on each run?

error_reporting(0);

$array1 = array();
$time1 = time();

for ($x=0; $x<1000000; $x++)
{
	if (count($array1)==0)
	{echo $x;
	}
}

$time2 = time();

for ($x=0; $x<1000000;$x++)
{
	if(!$array1[0])
	{echo $x;
	}
}

$time3 = time();

echo ($time2-$time1)."\n";
echo ($time3-$time2)."\n";

The results?
99937
36

More than 2,500x difference.