How a server works

Gerald Roger Clough

The web server is not a complicated mechanism; I believe this to be true for both static and dynamic pages.   This relatively simple (at its basic levels) technology forms the backbone of the World Wide Web.   See:   Birzniek and Hughes at http://www.serverwatch.com/tutorials/article.php/1407961 .

The static page operates in this manner and order: 1) a request is made by a user,   there is a communication using http protocol that processes the user's web server request—often a document (which can be a moving mpeg);   2) using a storage device, the server looks for the document in a file system; 3) web server retrieval from the storage device and then forwarding of   requested document; 4) the browser displays the initial request results on user's screen.   A Web server serves static content to a Web browser at a basic level.    See: Birzniek and Hughes.   “The beauty of this simplicity is that it has led to much more complex information exchanges being possible between browsers and Web servers.”   Id.     The server is not being asked to do a whole lot and absent a huge number of hits (which of course is what you're hoping for and therefore needs to be considered in the context of load balancing) the static page does not possess the problems and challenges that the dynamic page presents.

The dynamic page is used for things such as calculations where the user submits input to the server, asks the server to do something like make a calculation and return an answer to the user.   An apparently meaninglessly named but useful standard called Common Gateway Interface dictates how data gets passed back and forth between the server and its application.   These CGI programs are the most common way for the web servers to interact dynamically with a web user.   Each time a CGI “script” is executed a new process is started and this is can slow down the server (something to think about because a wave of automated purchases obviously will require these sorts of calculations).   There are alternatives to CGI which include technologies designed to work on the client side rather than at the server.  

A web server has two major components: web server software and web server hardware.

Any computer can be a server.   In order to be configured as a server, a person must acquire the server software.   This can be acquired without cost from outfits such as Apache and of course can be purchased from many other companies.    Apache seems to be a very good product—built in search engine; many modules available and increasing; comprehensive security features including the support of SSL.    According to Bizniek and Hughes a   Web server should be designed around a certain set of basic goals:

1) accepting network connections from browsers.

2) retrieving content from disk/ file (generally static).

3) run local CGI programs (in the case of the dynamic page).

4) transmit data back to clients.

5) be as fast as possible.   

Obviously in the real modern world (ie., BPR involving automated sales for instance), the dynamic page is going to be the page that is going to be the minimal expectation and people are relying on.   This is so because because, as Bizniek and Hughes explain:

Dynamic content typically relies on heavy database usage or processing of other program code, which takes up many server-side resources.

Another problem comes up when running a Web site that has grown popular beyond its immediate means of serving content and ways to spread this load out -- usually across multiple machines, and sometimes across multiple sites.   There are a number of ways to achieve load balancing.

See:   http://www.serverwatch.com/tutorials/article.php/10825_1407961_6

According to Bizniek and Hughes, load balancing is “really just a trick” in that improvement of a single web server has not improved but rather external techniques are used to spread the load among many equivalent web servers.   Boosting the resources available by boosting disk speed, memory and CPU power are some obvious and basic ways to spread this load.

There are a number of ways to load balance and these should be studied.   Bizniek and Hughes discuss a number of ways to balance the load on the dynamic web pages that can be the heart of an automated sales system.   The consequences of the “server going down” are known maybe even to the layman who is bombarded by IBM commercials during every Sunday in the fall.   Because so much rides on the server proper preparation and implementation must be given very high priority.