Web farms, whether they are powered by open source Apache or Microsoft's IIS, often require serving up Web content so quickly that the CPU/chipset conservation models we tested as part of our "green" operating system assessment would be of no use.

In addition to these CPU hogging requirements, Web farms built around virtualized hosts (often deployed for convenience sake) aren't going to get any green benefits from today's server power-saving measures because virtualization techniques push CPUs to full-on operation all the time (see related story).

That said there are hopes for greener pastures for non-virtualized Web server farms. Multicore servers from Sun equipped with UltraSparc chips and x86 multi-core servers from Intel, AMD, and VIA Technologies that offer CPU speed control with power throttling capabilities can spawn CPU threads that service requests on specific cores and then slow the CPU to a power-savings state on the remaining cores.

That's the good news. The bad news is that such power savings comes at a cost. CPU thread spawning setup and tear-down happens neither inherently nor by default in any Web daemon or within any application environment. It must be a part of the application coding, in that it requires developers to consciously choose thread spawning to specific cores and then clean up their processes for a shutdown. This is not a trivial task, as the library calls and the code required to do this have only recently became available for programmers to replicate and use.

A second way to address power savings in the face of the unpredictable nature of how and when users access Web applications is to employ predictable load balancing by allowing groups of Web servers in the farm to shutdown in an organization. Web site load balancing -- the act of spreading traffic and application loads across numerous servers -- is a practice that detects user requests and parses the requests across numerous servers. This provides opportunities to limit balanced servers into smaller pools depending on time shifts. As constant 24/7 site traffic is a rarity, pools can be shrunk and enlarged to conserve power to match daily traffic patterns, suiting time-of-day loads. For example, if the largest loads are between 1300 to 2100 hours and loads predictably drop off at other times, it's possible to rebalance server pools to shrink the overall size of the pool — thus leaving some servers to power down. The same potentially holds true for multicore balanced Web delivery systems.