[Top] [Prev] [Next] [Bottom] [Contents]

Server-Side Scenarios

A concrete example will serve to illustrate the advantages of client-side applications. Imagine that your organization wants to create a Web-based calculator application. WWW users will be able to go to your site and use this application to perform calculations from anywhere in the world. It's up to your team to decide how to implement this application. Using server-side technologies, calculator design might go something like this.

1. You first design a HTML page with

a set of text fields for numeric input,
a hidden element for state storage,
a list of operations to perform,
and some submit buttons.

2. You spread the word about your new WWW page. Someone, somewhere, comes upon your page and decides to do a calculation.

3. The user enters a number and clicks the Enter button.

4. The user's browser posts a request to the HTTP server.

5. The server sends this request to the server-side application which will process the request. This application is running on your organization's machine.

6. The server application recreates the state of the calculator "object" from the form arguments.

7. The server application performs the operation.

8. The server application creates a new HTML page that displays the results. It converts the state and stores it somewhere. This state information allows your calculator to "remember" and evaluate expressions with multiple operators entered in several steps-for example, 3+4\xb0 5÷6.

9. The user's browser gets the return HTML stream and renders the new document on screen.

10. The user can perform another operation.

Optimization

Let's analyze and try to optimize this server-side application.

The server-side calculator requires unnecessarily complex coding. This coding can be considered a patch to an unsuitable architecture.
This approach is unnatural to the programmer and requires proprietary code.
This approach keeps the developer from doing the real application.
This approach requires many resources on the server Web site.

To ease the coding of the complex state retrieval and storage mechanisms that working on the server side has necessitated, you decide to encapsulate the mechanism into some base classes. Each server-side class will read and write itself to HTML streams. The result?

This gives the developer a higher level of abstraction, but still requires some coding.
The display or view code is tied into the object and that will only go so far (new displays take new development).
All the other limitations remain.

Scaleability

You've built and optimized your Web-based calculator. Everyone agrees that it's a fine piece of programming, and you install it on your Web site for the world to see. What happens?

: 1. Let's imagine 10,000 client browsers try to use your calculator. Each user wants to add 20 numbers in the next hour. That would require 200,000 runs of the server app's algorithm. If the users keep this up over the course of an 8-hour work day, that comes to 1,600,000 runs of the server application's algorithm.
: 2. This is quite a load, since you want to deliver other WWW pages as well, so you upgrade your server machine to a quad Pentium 166 (or SPARC 20) with 260 MB of RAM. You also decide to use one of the Web server APIs (NSAPI or WRBAPI) to increase performance a little. This arrangement allows you to meet the current demand.
: 3. Your development team, excited by their award-winning calculator design, develops a "rudimentary" spreadsheet application using server-only programming. You install this new application on your WWW site, and after a few weeks the spreadsheet is generating 10 times as many "hits" as the calculator did-16,000,000 server hits a day from 100,000 users.
: 4. To meet this new demand, you decide to try load balancing. You upgrade your Web site again, this time to 10 quad Pentium 166 (or SPARC 20) machines with 260 MB of RAM each. You then configure the server applications for load balancing and mirror the sites.
: 5. Now your site is humming nicely. Your site is considered to be one of the "best of the Web." This attracts more users, and at all hours of the day. You now have 300,000 users performing 20 calculations an hour 24 hours a day. Your hit count (not user visit count, which is what you see when you visit many sites) is now 48,000,000 daily, assuming each user uses your site 8 hours a day. What do you do? Use 300 quad Pentium 166 machines, mirrored constantly?
: 6. The development team has a new server-side application. This one promises to be even more popular than the spreadsheet.

You can see how things could get out of hand at an installation where an inappropriate architecture has been used.

This is not solely a Web-related phenomenon: such stress-failures have been seen throughout the history of computer and other systems.

One famous recent example: the British government was faced with overloading on a pair of motorways connecting London and Birmingham in central England. It was reasoned that a third, more direct, route would alleviate matters. Six months after the new route was opened, all three roads were overloaded! The third road attracted wholly new travelers.

[Top] [Prev] [Next] [Bottom] [Contents]

info@bluestone.com

Copyright © 1997, Bluestone. All rights reserved.