Does Multimedia Have a Dark Side?
Selecting the right format and configuration
can make or break your site
By Don Larson
You've probably encountered some form of this doomsday scenario by now: The backbone of the Internet may have been designed to withstand nuclear assault, but it will never survive the onslaught of multimedia on the Web. Static pages will become passe',
the story usually goes, so more Web sites will be forced to add audio, video, and animation just to keep pace. And eventually all of these overstuffed files are going to load the Net with so many packets that it is slowly going to grind...to...a...halt. Serious--even scary--stuff, for sure. "Good thing it's MCI's problem," you think, "and not mine."
But what if, instead of bringing the entire Internet to its knees, a similar packet jam began plaguing your site specifically? Suddenly, the Web server can't handle all its requests. Response time begins creeping toward double digits. Your T1 connection, with all that extra bandwidth you thought you would never need, begins to bulge. Ultimately, traffic on your site drops measurably, and your beeper is almost worn smooth. Are you worried now?
Regardless of how many requests you serve, you can take several steps to help avoid worst-case scenarios like the one above. We'll help you make the right decisions about which multimedia formats to employ, and answer your questions about extra server load and bandwidth constraints. In addition, we'll analyze the effect that large audio and video files might have on server performance, offer some tools you can use to monitor server demand and throughput, and even let you in on advice from Webmasters of some of the most media-intensive sites on the Web.
Fun With Formats
One of the first problems multimedia presents is deciding which formats to support. Perhaps one of the most useful ways to categorize the formats is into two groups: the familiar, "self-contained" standards like AU, WAV, MOV, and MPEG; and the more recently emerging "streaming" standards such as those put forth by Xing Technology Corp. and RealAudio. "Self-contained" simply means that the file doesn't require any additional server software beyond a Web (HTTP) server. Multimedia formats that employ data streaming--a process that allows files to begin playback before they are completely downloaded--require special (usually proprietary) servers for processing.
Of course, there's little point in putting multimedia on your page if only a handful of visitors have the applications necessary to enjoy it. So information regarding client-side support is also a crucial factor in format choice.
Here's how some of the most common formats measure up:
- Self-Contained Audio Standards: The three most widely deployed Internet audio formats are AU (Audio, or m-law); WAV (Waveform Audio); and AIFF (Audio Interchange File Format). Although these formats were de facto audio standards before the Web was created, they owe their widespread Internet acceptance to early support by the helper applications incorporated into browsers such as Netscape Navigator and Mosaic. This cross-platform support, and the ability to run natively within a browser, continue to make these formats prime candidates for adding audio to a site.
The AU file format is the closest thing to an open audio standard on the Internet. First introduced by Sun Microsystems and NeXT Computer, AU continues to dominate non-proprietary audio files in terms of sheer numbers. In fact, even large music sites that boast "hi-fi" sound, such as the Internet Underground Music Archive, continue to offer the comparatively low-fidelity AU format. This is due primarily to AU's 2:1 compression ratio, which gives the format a relatively small file size of about 8 KB per second of audio. "Due to compression, AU files are friendly to server load and are downloaded relatively fast compared to equivalent audio clips in other formats," says Ryan Melcher, senior multimedia specialist at IUMA. "Their sound quality, however, leaves a lot to be desired." For this reason, Melcher concludes, AU files are best reserved for sound effects, speech, and short music clips.
The WAV file format enjoys wide support as the audio standard for Windows, which has more than 80 percent of the platform share on the Internet. While the WAV standard offers higher-quality sound than AU, it comes at a price. For a CD-quality WAV file sampled at 44.1 KHz, at 16-bit resolution with 8 bits per byte, factoring in two channels for stereo, just 60 seconds of audio will consume more than 10 MB of disk space.
AIFF is the WAV equivalent for the Apple Macintosh platform. "AIFF files are best known for the fact that they remain true to the original recording," says Melcher. But like their WAV counterpart, Melcher says, AIFF files will create "big-time bandwidth suckage if high fidelity is what you want." Thus, both WAV and AIFF are commonly used on the Web only at lower-quality sampling rates to keep size reasonable.
- Streaming Audio Formats: Two relatively new standards, MPEG (Moving Pictures Expert Group) and RealAudio, are quickly changing audio on the Internet. Although MPEG is probably best known as a standard for the compression of video files, it also offers a similar compression standard for audio files. MPEG claims astounding compression ratios as high as 26:1, although ratios greater than 12:1 are seldom used due to sacrifices in quality. Even at this "modest" compression, the benefits of MPEG are clear, in that it allows you to deliver CD-quality audio files that in any other format would be virtually unmanageable.
Although MPEG's Web use has been limited by serious hardware requirements for decoding and decompression, the introduction of software-based MPEG applications to the Internet has helped this format spread rapidly. One of the most popular is the XingMPEG Player from Xing ("zing") Technology Corp.. Available as a plug-in for Netscape Navigator, the Player can be used in conjunction with Xing's Streamworks server software to deliver a powerful combination: MPEG compression and data streaming. By avoiding the long download delay typically associated with large multimedia files, streaming is a blessing for end users. However, the technique can be quite taxing where Web servers are concerned, as we will discuss in more detail.
One of the fastest-growing proprietary streaming formats is Progressive Networks' RealAudio. Though available on the Web only since the middle of 1995, the RealAudio Player enjoys an ever-expanding client base of more than 5 million users, according to the company's count. Like XingMPEG Player, RealAudio Player allows users to download both on-demand and live-broadcast streaming audio files. The RealAudio file format supports two levels of compression: an "AM sound" quality for 14.4-Kbps modems and an "FM sound" quality for 28.8-Kbps and faster connections. Depending on which algorithm is used, RealAudio files typically require only 1.1 to 2.4 kilobytes per second, or between 3.6 MB and 8 MB per hour of audio. This ability to deliver audio in readily accessible data streams positions both the RealAudio and XingMPEG formats as the audio standards of the future.
Finally, for those who want to deliver speech over the Net using a minimum of bandwidth, Voxware Inc.'s MetaVoice (VOX) format is the clear choice. Using a unique low-complexity algorithm, MetaVoice compresses voice files at ratios as high as 55:1. At low-bitrate quality, therefore, VOX audio files weigh in at a low 1 MB per hour. VOX files are also delivered at a very low rate of 2,400 bps, so they consume little bandwidth. In addition, MetaVoice files do not require any special server software, because they can be transmitted by any standard Web server. Although the ToolVox client is compatible with any browser, the VOX file player can also be used as a Netscape plug-in to deliver streaming audio.
- Self-contained Video Standards: Like its AU audio counterpart, the QuickTime Movie (MOV) format is the closest thing so far to an Internet video standard. Originally developed by Apple Computer, the MOV file type runs natively on the Mac platform, while Windows users are required to download the QuickTime for Windows.
Because movies involve both audio and video, video files as a rule are extremely large, and QuickTime files are no exception. Even though QuickTime supports compression ratios as high as 50:1, a typical MOV file consumes almost 70 KB per second of video, or about 4 MB per minute.
With compression ratios as great as 200:1, MPEG video files are usually smaller than QuickTime movies. For full-motion video (30 frames per second), a typical MPEG video requires about 45 KB per second, or 2.8 MB per minute of video. However, as with MPEG audio files, MPEG video has historically required special hardware and high processing power, reducing its client-side support. Only recently, with the advent of software-only MPEG players like XingMPEG and Duplexx Software's NET TOOB, has the MPEG format become a viable alternative for video on the Web.
Finally, AVI (Audio Video Interleave) is Microsoft's proprietary Video for Windows format. Like its WAV counterpart, AVI's widespread acceptance is due to native support by the Windows Media Player application. AVI's average file size generally falls somewhere between those of QuickTime and MPEG.
- Streaming Video Formats: Xing's Streamworks server and MPEG compression can also be used to deliver video over the Internet. Due to the large amount of data transfer that video demands, however, only surfers connecting at modem rates of 28.8 Kbps or higher will be able to view these files. Even at 28.8, the best quality a Streamworks server can deliver is about two low-quality video frames per second. Only those users connecting at T1 speeds will be able to escape this choppy, "freeze-frame" picture quality (often referred to as "slide-ware") and enjoy full-motion video.
Companies such as VDOnet, however, have already discovered methods of compressing video so that it can be delivered at rates as high as 8 to 12 frames per second for 28.8 users and 2 to 3 frames per second for 14.4 modems. And client-side support for the VDO format has grown accordingly, as more than 1.5 million VDOLive players have reportedly been downloaded by end users. VDO uses a "wavelet" method to compress AVI files into its proprietary format. Although compression ratios vary, VDO files average about 1 MB per minute of video.
Server Strains and Bandwidth Bottlenecks
Once audio or video is ready to go live, Webmasters face more complex challenges, involving the effects of large multimedia files on response-time latency and overall server performance. For those sites choosing to serve the self-contained multimedia formats via Web servers, factors such as bandwidth constraints and maximum serving capacity are crucial to overall performance. Meanwhile, serving streaming multimedia poses a separate, though not unrelated, set of challenges to bandwidth and server consumption.
Considering how widely implemented Web (HTTP) servers have become over the past two years, little is known about how they perform under actual working conditions. However, a recent study conducted by Dr. Louis Slothouber, a computer scientist with StarNine Technologies, is beginning to shed some light. The report, titled "A Model of Web Server Performance",takes a look at the interrelation of network bandwidth, server load, and average file size and its effect on server response time and performance.
Some of the study's findings come as no surprise. For instance, the most common bottleneck for any site is available network bandwidth. This is due to the fact that almost all commercial-grade Web servers can transmit files at speeds that exceed common ISDN (128 Kbps) and T1 (1.56 Mbps) Internet connections. Serving a number of large multimedia files is, therefore, especially problematic when a site's network connection is constrained. As Jonathan Rosenberg, executive vice president of technology for c|net says, not only do the files eat up more bandwidth during transmission, they tie up connections even longer. In the long run, these connections make it easier for a server to run out of TCP/IP kernel resources.
This fact is a little ironic, because the Internet was designed for long-lived connections, which actually make very efficient use of network capacity. "The truth is," Rosenberg says, "from a technical point of view, one should welcome these large media types, since they're much more efficient."
Where Slothouber's study breaks new ground is in the direct correlation of increased file size and server performance. The report demonstrates that as average file size increases, as with large multimedia files, the maximum serving capacity--the total hits per second that can be processed--of a Web server decreases exponentially. "This result is primarily based on limitations of network bandwidth," Slothouber confirmed, "and it is true regardless of the server being used--even infinitely fast servers! Thus, multimedia-rich Web sites that contain many large audio and video files are particularly susceptible to slowdowns caused by insufficient network bandwidth."
According to Slothouber, with an infinitely fast server on a T1 connection, a typical Web site (average file size around 5 KB) could expect a maximum serving capacity of about 35 hits per second, or more than 3 million hits per day. However, if the average file size jumps to just 80 KB, the maximum capacity would drop to about two hits per second, or 170,000 hits per day--a decrease of almost 94 percent!
Equally unprecedented are the study's findings concerning the Web server as a significant bottleneck in performance, typical for sites with high-speed T3 (6 Mbps) connections. A commonly held assumption about servers is that they can handle an almost infinite number of simultaneous connections, though response time and throughput suffer gradually as server load increases. The thinking concludes that eventually all the requests get processed and each visitor is served, albeit slowly. But according to Slothouber's report, a Web server's performance does decrease gradually, almost imperceptibly, up to a certain point. However, if the load on the server continues to increase beyond this point, response-time latency increases toward infinity, and the server becomes completely deadlocked. In this state, the server will attempt to continue processing more and more requests at ever-decreasing speeds, until virtually no files are being served at all.
This load ceiling, therefore, represents a Web server's maximum capacity, or the total number of hits it can serve in a given time. As with bandwidth bottlenecks, this upper limit is affected greatly by the average size of the files being served. Again, this is due to the fact that larger files tie up connections for longer periods of time, thereby decreasing the total number of connections available at any one time.
The Stress of Streaming
As you can probably imagine, if persistent connections are a problem with self-contained multimedia files, they are definitely going to be bad news when used with streaming multimedia formats. Real-time audio and video represent the ultimate in long-lived connections: A single RealAudio clip can be hours long, and live feeds can run indefinitely. Theoretically, a listener could tie up a stream for the duration, though RealAudio's online information reports that average connection time is more like four minutes. These long-lived connections are most problematic when the streaming server and Web server reside on the same physical machine--a situation that places the two in competition for a limited number of available connections and system resources.
Streaming media's use of server resources is a relatively small concern compared to its consumption of available bandwidth, however. As with self-contained files, the streaming formats also make efficient use of the data pipe, because streaming spreads the flow of data out over longer periods of time, whereas a typical Web server sends data as fast as possible in a quick, bandwidth-intensive burst. But due to the large amount of data that must be transmitted for audio and video, the portion of the pipe filled up by multiple streams can be quite large. Even at low bandwidth AM-radio quality, each RealAudio stream requires 10 kilobits/second. Translated into the maximum number of simultaneous connections, this means that just five to 10 streams will fill an ISDN line, while a T1 can handle a more suitable maximum of 100 concurrent connections.
Video streaming is even more taxing on available bandwidth. In fact, at 112 Kbps, a single stream of XingMPEG video at full-motion (30 frames per second) quality consumes more than 10 times the bandwidth of the RealAudio example above. Even at T1 connection speeds, therefore, 12 simultaneous connections will saturate the data pipe. As these figures show, in the case of both audio and video streaming, a popular site can quickly and easily reach maximum. Thus, proper planning and some highly scalable server solutions are essential for success with streaming-media formats.
Server Side Solutions
The all-encompassing answer to avoiding the dark side of multimedia is reminiscent of MTV's old slogan: "Too much is never enough." Because bandwidth is almost always the problem for sites serving at less than T3 speeds, raising your notch on the data-delivery chain improves performance across the board. Upscaling to higher processing speeds and adding RAM or additional boxes are also obvious solutions. This is often the approach of large sites such as c|net, which maintains at least 30 percent headroom on all resources, even under the heaviest load. As Rosenberg puts it, "I think the best advice is that if you are worried about delivering multimedia, you are doing something wrong. Overengineer your system. It's the only hope, given the growth of the Web and the need to react quickly."
Slothouber's report offers more specific insight into which of these antidotes will best solve your site's needs. It confirms that increasing network bandwidth greatly improves both a server's response time and its maximum serving capacity; in fact, when the network connection is the culprit, the relationship between available bandwidth and the server's load ceiling is approximately linear. So doubling your data pipe would effectively double your hit capacity, up to the server's total maximum capacity.
The server deadlock situation described above can be remedied fairly easily as well, at least for those with Web servers on the Mac or Windows platforms. This deadlock occurs when the total number of incoming requests exceeds the rate at which the Web server can process jobs waiting in the queue. By limiting the maximum number of simultaneous open TCP/IP connections, therefore, site administrators can ensure that the server will never exceed its maximum hit capacity--the point at which response time increases to infinity. However, finding the magical number of maximum connections so that your server will run at peak levels may require some trial and error, says Andrew Dimsdale of Netrex, a high-end Web hosting service. Although Netrex's hardware and Internet connection have little problem handling peak load periods, says Dimsdale, "it is when the TCP/IP max connects is exceeded that you have to worry. Then it becomes a juggling match between memory and processes allowed per Web server--a black art."
Why is deadlock not such a threat to servers on Mac or Windows platforms? On these machines, the maximum number of connections is limited automatically, either by the hardware itself or the server software. Unix or Windows NT boxes, on the other hand, allow a practically unlimited number of simultaneous connections. The irony, according to Slothouber, "is that it appears this 'feature,' often cited as the primary advantage of Unix-based servers, is in fact a curse."
Almost all of the Webmasters interviewed agree that the best way to avoid load problems with the streaming media is to place the server on a separate machine than the Web server. "The only dedicated media server we have is for RealAudio," says c|net's Rosenberg, because "the demands of the media are such that [it requires] a dedicated platform." A dedicated media server is a possible option for the self-contained formats as well. "It would definitely be an ideal setup to have more than one server for a multimedia Web site," says Melcher. "You could set up one for the text and graphics and the other for large audio or video files." Both Melcher and Dimsdale agree that a "true" Web server, such as a server from Sun Graphics' Challenge series, would be best suited for the job. The essential minimums for such a machine, Dimsdale adds, would be a 150 MHz CPU with 128 MB of RAM.
One of the best configuration solutions for streaming media servers is to use a technique known as "fanout propagation." In this setup, one server originates a streaming data file and passes it along to one or more additional servers, which can in turn feed yet more servers or transmit the streams to end users. This branching effect exponentially increases the number of simultaneous clients that a site can serve. And, as Xing's online information claims, this method of distributed serving so disperses the data that "actual Internet backbone traffic may be significantly less than the total bitrate delivered to all simultaneous users."
Monitoring Tools
Of course, it is difficult to know which solution will provide the best results without having the right information about your server's performance and your network connection. Although many site administrators get this information from "homemade" custom-coded programs, a growing number of methods are available for monitoring server load and throughput, user-perceived latency of your site, and available bandwidth. Here's a glance at some of the notables:
- WebStone, Silicon Graphics Inc. WebStone is quickly becoming the industry standard for benchmarking Web server performance. Although the program was developed by SGI, WebStone is offered as an open standard, and the code is freely available. Users can configure Webstone to simulate the load on a Unix server under a variety of site profiles, including media-rich environments. The tool measures a number of important output parameters, including total throughput in bytes per second, both connection and request processing latency, and total pages served per minute. Those in the market for a new server can use the WebStone benchmarks to compare products prior to purchase, as a number of vendors make these results available.
- WebTest, Mercury Interactive. While WebStone results are generated as raw data (although WebStone 2.0 is equipped with an experimental graphical user interface), WebTest gives users feedback via a Windows-based GUI. Available as an extension of Mercury's LoadRunner testing tool, WebTest allows users to build tests automatically by browsing a site. The program then generates test results in a variety of formats, including charts, graphs, and summary reports. LoadRunner is available for testing servers on both Unix and Windows NT platforms.
- OnTime Delivery, Timedancer Systems. In addition to testing your server with a simulated load, it is a good idea to monitor how well your server is performing under real-time conditions. To this end, OnTime Delivery provides one of the best (and, starting at just $2 a week, the cheapest) services for measuring your site's response time from an average visitor's perspective. OnTime routinely sends out requests for a list of URLs, which you define and update, and sends regular reports via e-mail. The reports include a detailed summary of the average response time for each page, a graph showing a statistical history of response time, and even a chart detailing how your site's performance compares against all of Timedancer's clients.
- CyberGauge, Neon Software. Don't forget that your connection to the Internet is often the culprit where access slowdowns are concerned. CyberGauge is a great tool for making sure you are getting the bandwidth promised by your ISP and for monitoring your use of available bandwidth. It's an Internet bandwidth utility that uses the Simple Network Management Protocol (SNMP) to perform real-time tests on the throughput of network routers, switches, and hubs. The program displays the results in customizable graphs, allowing you to monitor important parameters such as current consumption of bandwidth as a percentage or in packets per second. CyberGauge is currently only available for Macintosh.
Future Trends
Some of the most promising advances in Web-based multimedia are included as new JavaScript-based features in Netscape Navigator 3.0, as the new Navigator edges ever closer to becoming a complete multimedia client by bundling the LiveAudio and LiveVideo player consoles with 3.0. These enhancements allow site designers to use the <EMBED> command to integrate audio and video formats like AIFF, AU, MIDI, WAV, and AVI directly into an HTML page, effectively providing native support for the popular formats. Navigator 3.0 also comes complete with a QuickTime plug-in for Windows and Mac that finally gives streaming capabilities to the popular video format.
Tom Kidding, Websmith at Thomas Dolby's cutting-edge Headspace site, sounds the restrained excitement of Web developers: "It's a sad fact that many users get frightened away by the thought of having to download and install yet more plug-ins. We're very excited right now about Netscape Navigator 3.0's bundled LiveAudio, Live3D, and QuickTime plug-ins and are authoring in anticipation for the release of 3.0. As things develop with Microsoft Internet Explorer," Kidding says, "we will be looking into the supposed 'seamlessness' of ActiveX components and will weigh this approach against the Netscape's in terms of our multimedia content delivery."
With technologies continuing to push toward the seamless integration of multimedia in Web pages, improved compression techniques emerging at a fast pace, and the promise of broadband connections looming on the horizon, one thing is clear: Web-based multimedia will continue to grow in maturity and popularity. For now, if your resources are limited, it's wise to invest cautiously in future technologies and keep a watchful eye on the resources you already have in place.
--D.L.
Web Developer® Site Feedback
This article first appeared in Sep/Oct 1996.
Web Developer®
Copyright © 2000 internet.com Corporation. All rights reserved.
