InformationWeek.com

Welcome Guest. | Log In| Register | Membership Benefits

September 25, 2000

Printer ready

Web-Site Scalability
Business Drives Web Scalability

continued...page 2 of 3

More on scalability:

sidebar: One-Stop Access: Maintenance, Repair, And Operating Supplies

Host Provider Aims To Clear Up SLA Confusion (8/28/00)

Network Computing: No-Fail E-Mail (9/4/00)

Computer Reseller News: Staying Up Around The Clock (8/7/00)

TechEncyclopedia:

Send Us Your Feedback

Application-level failover is also vital. For instance, a load-balancing system may redirect a request to the server being queried the least--let's call it Server A. If Server A fails to complete this request, the user receives an error message and tries the request again. This is the simplest case; the user might be automatically rerouted to Server B. This time, the system redirects the user request to Server B, which successfully carries out the request.

The user can then continue operations with the application, but any contextual information entered when the user was working on Server A (for example, items added to a shopping cart) are lost when the request is redirected to Server B. In other words, a load-balanced system is not necessarily fault-tolerant. However, a fault-tolerant system is both load-balanced and distributed.

Simple load-balanced systems like the one above can guarantee only very basic fault-tolerance, which is called application-level failover. This type of failover guarantees access to an available application and lets users complete their requests, but session integrity isn't ensured. The failover level required on a Web site depends on the kind of services it offers and the type of transactions it executes.

Unlike application-level failover, ses-sion-level failover ensures that no user information is lost, no matter what happens, and even if users haven't fully completed their transactions. Of course, session-level failover is more complex to implement. In a system that implements this type of failover, processes are systematically distributed by the system, which handles the load-balancing mechanisms used to spread the load.

This fault-tolerant feature requires a certain amount of process redundancy, as well as mechanisms guaranteeing data persistence. Typically, the most important functionality involves preservation of user-session information. To carry out such tasks, application servers treat session management as a dedicated process called the session manager. The session manager should be redundant and distributed across the network.

For example, in Bluestone Software Inc.'s Total-e-Server application server, the session manager, which can be replicated and is called the Persistent State Server, is used to save the context state of each user session. Should an instance of the application server fail, the states can be reassigned to another instance. Other application-servers, such as Allaire Corp.'s ColdFusion, have only application-level failover included natively. With these systems, users need to program session-level failover manually.

Clustering can also be used to improve availability and performance. Clustering technology concerns a different architecture level--one that's made up of the operating system, the DBMS, and the application server. Generally, a cluster is a logical group of several servers that is "logically" regarded as only one server. The software that manages the cluster is responsible for distributing client requests. Clustered configuration is a classic deployment option that's available for all major database management systems, as well as for most application servers.

If there's one certainty, it's that hardware capacity will have to be increased sooner or later. Clustering technology makes this go smoothly, and in some cases, software solutions can even save money.

"We wanted to keep fast response time and reduce hardware costs," says Michael Tso, Inktomi Corp.'s director of engineering in the commerce division. "TowerJ, which compiles the Java pseudo-code to native machine code, helps us produce Java applications that are twice as fast on the same hardware."

Another viable strategy is local optimization, or the speeding up of a particular component. The Yahoo Everywhere portion of Yahoo, a portal devoted to wireless devices, handles huge volumes of pages and views per month. Yahoo teams began by developing some of their applications in Java, but in time, shortcomings of the Java platform began to show through.

Sridhar Ranganathan, engineering director for Yahoo Everywhere, says Java is too greedy in terms of CPU time. This drawback alone doesn't disqualify Java in all cases because it does allow for faster prototyping and development than C++, the other language used by the company.

Nonetheless, C++ remains the language of choice at Yahoo Everywhere for the applications in greatest demand. Yahoo Everywhere continues to use Java for fast time-to-market applications with limited deployment, but like Inktomi, Yahoo Everywhere uses TowerJ technology to optimize performance. "TowerJ has reduced the number of required servers by 50%," Ranganathan says.

Finally, it's extremely important to pay attention to application design. Ranganathan says that for Yahoo Everywhere's most important services, teams rewrite Java applications in C++. "Our experienced development team uses Java when we need fast time-to-market and C++ for its absolute speed and reliability," he says.