Chapter 5

COSC1300

Web Security Performance Measurement

n this chapter, we examine the performance of theweb server.

Table Of Contents

1: Introduction2: Performance Measurement 2.1: Measurement Purpose 2.2: Measurement Techniques 2.3: Metrics3: Performance Factors 3.1: Client 3.2: Network 3.3: Server4: Apache Performance5: Server Clusters6: Links

Indroduction

Chapter 3 discussed the HTTP protocol used to transmit web documents on the Internet,and the Apache web server - an example of an implementation using HTTP, and themeans by which web documents are made available.

Some of Apache’s configuration directives were introduced. In this chapter we willdiscuss some further directives - those responsible for determining the performance ofApache.

But first we will consider how we can measure the performance of a web server and thefactors that affect the performance of a web server, indeed, we will consider whatactually comprises a web server. This data will allow us to make informed decisionabout the setup of our server.

Web Security Performance Measurement

COSC1300 - Web Servers and Web TechnologyOnline Tutorials Materials

Copyright © 2001 Hugh WilliamsAll Rights Reserved

COSC1300

Introduction Measurement Techniques

2. Performance Measurement

n this chapter, we examine the techniques and value ofmeasuring web traffic.

Table Of Contents

1: Introduction2: PerformanceMeasurement 2.1: Measurement Purpose 2.2: MeasurementTechniques 2.3: Metrics3: Performance Factors 3.1: Client 3.2: Network 3.3: Server4: Apache Performance5: Server Clusters6: Links

Indroduction

Web measurement encompasses many forms of web traffic, and many ways to measureit. Web traffic data needs to be collected but also analysed to be of any value.

2.1 Measurement Purpose

Web traffic data can be used for different purposes according to the role of thoseexamining the data.

Content Creators

Content creators use web traffic data to understand the browsing behaviour of the usersof their site, including how they access certain resources (the links they choose) and alsowhat links to advertisers’ sites are selected and how often. This information maynecessitate a change in design for the site.

Content creators can also gain information about how the users access the site, and howthe site performs under methods of access (eg. telephone modem). This may necessitatein page redesign to improve the performance of downloads.

Web-Hosting Companies

Web traffic data is critical for web hosting companies. Fundamentally this informationwould be used to determine the number of bytes transferred for the site of each client,which is used to determine how much to charge each client, and how to allocate systemresources.

Network Operators

Network operators, for example an Internet Service Provider (ISP), would use webtraffic data to manage their network. This could include determining the benefit ofinstalling a proxy cache on the local network, or to compare the latency of usersconnected with high-band (eg. cable modem) to those connected with low-band (eg.telephone modem). Latency details of the network allow the network operator to decidehow to upgrade the network for new users.

Checkpoint

1. What is the primary reason web hosting companies use web traffic data?

Introduction Measurement Techniques



COSC1300

Performance Measurement Metrics

2.2 Measurement Techniques

n this chapter, we examine the techniques ofmeasuring web traffic.

Table Of Contents

1: Introduction2: Performance Measurement 2.1: Measurement Purpose 2.2: MeasurementTechniques 2.3: Metrics3: Performance Factors 3.1: Client 3.2: Network 3.3: Server4: Apache Performance5: Server Clusters6: Links

Indroduction

There are many ways to collect web traffic data. By handling requests web serverscollect data through logs, although the information logged this way is usually limited. Itis also possible to specifically monitor the traffic moving on a network.

Logging

Servers generate logs as they process requests from clients. Every entry in a serveraccess log represents a HTTP request to the server and includes information about theclient. Normally by default server log entries only contain the request method and serverstatus code to minimise the overhead of logging. It is possible, however, to log moreinformation, including the request and response headers.

Server logs could be used to analyse user browsing behaviour, to determine, forexample, the most popular page on a site. However the log cannot record how often thepage is requested via cache (and it is more likely that popular pages will be retrievedfrom cache), and without denying caching on all pages on a site (which will significantincrease the amount of web traffic - and is what caching attempts to avoid), logs cannotbe used to provide browsing information.

Common Log Format

Logging is usually done in the Common Log Format (CLF). This is a default industry

standard that provides basic information about each HTTP request, as follows:

Remote Host identity of client, either the IP address or the domainname

Remote Identity the account of the client, usually not implemented

Authenticated User the username of the client if authentication is used

Time the time the request was made, at one second granularity

Request corresponding to the first line of the HTTP request

Response Code the server three-digit response code

Content Length the number of bytes associated with the response

Extended Common Log Format

The extended common log format (ECLF) is based on the common log format but addsa number of additional fields. The number of fields added is not specified, but includes:

User Agent the name and version of the software that made therequest

Referer the URL of the web page where the user issued therequest

Request Processing Time the number of seconds the server spend generating theresponse

Request Header Size the number of bytes in the header of the request

Request Body Size the number of bytes in the body of the request

Remote Response Code the three-digit status returned by the server’s response

Remote Content Length the number of bytes in the response message

Remote Response Header Size the number of bytes in the response header

The combined log format is an implementation of the extended log format.

Packet Monitoring

It is possible to use software to directly monitor the traffic on the network. Logs provideno information about how web traffic affects the TCP and IP layers. A packet monitorcan produce detailed traces of web activity at the HTTP, TCP and IP layers which canbe used to determined the efficiency of the network.

Active Measurement

To allow systematic investigation of the performance of a server, active measurement,or testing, is required. Requests are generated in a controlled and predetermined manner,usually with a modified HTTP client, and the performance of the server is observed.

In the process of testing a webserver, the following issues should be addressed:

1. location of the test client

2. what requests are generated 3. what data to collect

The location of the test client is important as local clients (a client on the same machineas the web server) will not take into account network latency.

It is usually straightforward to generate multiple concurrent requests for a single webresource, but more difficult to accurately model the browsing behaviour of usersconnecting to the web server. A webserver may perform poorly under productionconditions while performing well under test conditions, because the nature of the testdoes not properly reflect the real world.

The test clients can record much information, including timestamps of DNS queries, theTCP connection, HTTP transfer, and the time taken to completely return a web page.However without further investigation, this information may not give a fullunderstanding of where the delays, if any, are occuring.

There are many tools available to test web servers, including ab (ApacheBenchmarking) which is included with the installation of Apache. Please see the Linkssection for a list of only a few web server benchmarking tools.

Limitations of Web Measurement

Obtaining data about requests to web servers can provide important information.However there are situations where this data is inadequate, or misleading.

Logs, as mentioned above, usually does not recorded the request and response headers,but it is possible to infer some header information from the fields that are recorded. Therequest URL can be use to infer the Content-Type header of the requested resource, forexample requests for resources ending in .html are most like for HTML pages. Also,certain response codes can be used to infer headers, for example the response code 304Not Modified implies that the request may have included a If-Modified-Since header.

Checkpoint

1. The combined log format has two extra fields of information (beyond that of theCLF). What are they?

2. Why can’t logs be used to accurately determine browsing behaviour?

Performance Measurement Metrics



COSC1300

Measurement Techniques Performance Factors

2.3. Metrics

n this section we discuss measurement values of webserver performance.

Table Of Contents

1: Introduction2: Performance Measurement 2.1: Measurement Purpose 2.2: Measurement Techniques 2.3: Metrics3: Performance Factors 3.1: Client 3.2: Network 3.3: Server4: Apache Performance5: Server Clusters6: Links

Web performance can be analyzed from different viewpoints. For instance, a serveradministrator’s perception of performance has to do with fast response time and noconnections refused. On the other hand, a Web master’s perception of performance is orientedtowards high connection throughput and high availability. Thus, it is difficult to formulate auniform set of metrics to measure web performance that is equally acceptable to both parties.Here, we concentrate only on the server administrator’s point of view.

Performance Metrics

Latency and throughput are the two most important performance metrics for web servers. Therate at which HTTP requests are serviced represents the connection throughput. It is usuallyexpressed in HTTP operations per second. Due to the large variability in the size of webresources, it is sometimes expressed in bits per second (bps) as well. However, it is unfair to simply compute the overall throughput, since different resource types(say documents, images, database requests etc) have typical sizes and hence differ slightlyfrom each other in their throughputs. Therefore, a more generalized approach would be tocompute ‘‘Class throughput’’ for different resource types and finally compute averagethroughput.

The following example illustrates how this formula can be used to compute the averagethroughput of a web server.

Example: http://yallara.cs.rmit.edu.au:8002 was monitored during a 30 minutewindow and 9000 HTTP requests were counted. This server delivers three types ofresources: HTML pages, images and database requests. It was observed that HTMLdocuments represent 40% of the requests and are about 11200 bytes long on average. Imagesaccounted 35% of the requests and their average size was 17200 bytes. Database requestsrepresent the rest 25% of requests, and their average size was 100000 bytes. Compute theweb server’s average throughput.

HTML Pages = (9000 X 0.4 X 11200 X 8) / 30 X 60 X 1024 Kbps (Kilobits per second) = 175 KbpsImages = (9000 X 0.35 X 17200 X 8) / 30 X 60 X 1024 Kbps (Kilobits per second) = 235 KbpsDB Results = (9000 X 0.25 X 100000 X 8) / 30 X 60 1024 Kbps (Kilobits per second) = 977 KbpsAverage Throughput = 1387 Kbps

The time required to complete a request is the ‘‘latency at the server’’, which is onecomponent of the total response time. The average latency at the server is the average time ittakes to handle a request.

Apart from the latency at the server, the time communicating over the network and theprocessing time at the client machine are also significant components of the client responsetime.

Another important metric, though one with a negative effect, is the error rate. An error couldbe any failure by the server, for example, an overflow on the pending connection queued atthe server end. This means that, an attempt by a client to connect to the server will be ignored.Increased error rates are an indication of degrading performance.

Measurement Techniques Performance Factors

COSC1300 - Lecture Notes Web Servers andWeb Technology

Copyright © 2000 RMIT ComputerScience

All Rights Reserved

COSC1300

Metrics Client Performance Factors

3. Performance Factors

n this chapter, we introduce the factors that affect theperformance of the web server.

Table Of Contents

1: Introduction2: PerformanceMeasurement 2.1: MeasurementPurpose 2.2: MeasurementTechniques 2.3: Metrics3: Performance Factors 3.1: Client 3.2: Network 3.3: Server4: Apache Performance5: Server Clusters6: Links

Introduction

Each of the elements that make up the Web Server, from the software to the hardware,will have an effect on the performance of the Web Server. But the overall performanceof the full process - the client requesting a resource across the network to the WebServer - is affected by more than the Web Server. The other crucial elements in thisprocess are the client, another computer running, typically, browser software, and thenetwork itself.

Client

The client is the computer from which the request is initially made. A client is typicallya computer running browser software, but also many other applications. Obviously withso many users on the world wide web, the variation in the configuration of both thesoftware and hardware of a client is enormous.

Network

The network upon which HTTP transactions are completed is, of course, the Internet.Because of IP, even though the many networks that the Internet consists of are different,the Internet can be considered as one homogenous network.

Still, a HTTP message must travel through many types of networks, and many routers.Each leg of its journey adds to the overall time.

The network is usually the most significant bottleneck in the process of requesting andreceiving a web resource.

Server

The server must receive a request and respond with the resource as quickly as possible.After the network, the server, for a number of reasons, is often the next majorbottleneck.

Checkpoint

1. Although we can tune our webservers, usually, where does the greatest latencywhen data is delivered across the Internet?

Metrics Client Performance Factors



COSC1300

Performance Factors Network Performance Factors

3.1 Client Performance Factors

n this chapter, we examine the factors that affect theperformance of retrieving a web document from a

server from the client’s point of view.

Table Of Contents


Hardware

The client hardware is the typical hardware of a PC. The general discussion of hardwarehere is applicable to servers also.

A computer, primarily, consists of a CPU, RAM (Random Access Memory), a Bus, aHard Disk, a Video card, I/O (input/output) and other peripherals.

Central Processing Unit

The Central Processing Unit (CPU) provides the processing power to the computer. Theimportance of the CPU is often overrated - it is only significant for process intensiveapplications, like rendering images.

Memory

RAM (Random Access Memory, or just Memory) is where all the computing activitiesare ideally stored while not being used by the CPU. RAM is potentially a very importantfactor on a machine involved in a web transaction. The more RAM the better because alarger cache can be supported.

The cache is where frequently accessed data (for example web pages) are kept in casethey are required again soon after they are stored.

Bus

The Bus is the part of the motherboard the moves data between the different parts of thecomputer. Bus speed is not usually significant on the Internet, but a slow Bus may makea fast CPU redundant as the CPU is forced to wait for the Bus.

Disk Drive

The Hard Disk is important because it is significantly slower than Memory. Ideally, alldata would be kept in the cache (in Memory), and therefore the Hard Disk would not berequired. Use of the Hard Disk is more applicable to the Web Server which may have toretrieve a document from the Disk to deliver it to a client (see below).

Video Card

The Video card is important to ensure smooth transitions between graphically presentedsoftware, but is not critical as part of the client hardware.

Input/Output

Input/Output (I/O) is the facility of the computer to send and receive data to otherremote hosts, through the serial (or COM) port. For a modem connection, which isapplicable to most hosts on the Internet, it is important to use the most up to date versionof UART, the chip that controls the serial port. UART provides buffering to managedata coming from the outside, through the modem connection, and to deliver it to thesystem bus.

Operating System

The are three main OS (operating systems) used on modern PCs - Windows, Macintosh,and Unix (or a variation). Obviously Microsoft Windows dominates the market.Although for performance it is advisable to use a Unix style operating system (eg.Linux) over Windows, for most users this is not an option due to the additional expertiserequired to install a Unix style OS.

Software

Web browsers provide a quite basic function. A browser makes a TCP virtualconnection to a web server (using a socket pair), and requests a document following thesyntax specified by HTTP. Once the document arrives, it is parsed by the browser, thendisplayed.

First the browser parses the URL entered by the user (or recognised when a link isclicked).

Then the browser checks the cache to see if the document has been previously stored. Ifso, either the page is displayed immediately from cache, or a HEAD request is sent tothe server to check whether the cached page is out of date. If the cached document isstill current, it is displayed immediately from cache. If the requested document isn’t inthe cache, or the cached version is out of date, then the browser must request the page

from the server.

The browser connects to the server by determining the server’s IP address. Because theURL provided is usually a fully qualified domain name, this must be converted into anIP address. This is done by the DNS. The browser makes a query to the local nameserver, which either has stored the mapping of the IP address to the domain name, orknows which server on the DNS hierarchy to query. Either the IP address is returned,eventually, or an DNS error results and the connection cannot be made. The manner inwhich DNS lookups are implemented mean nothing else can happen during the DNSlookup. This has the potential to be a performance issue if the local DNS server is downor overloaded.

Once the browser has the server’s IP address, it establishes a TCP connection uponwhich it makes a HTTP request. In doing so, the browser checks for previously receivedcookies associated with the resource it has requested, and sends these with the request.

The browser waits until it receives a response from the server, or a timeout.

Once the response arrives, the OS delivers it to the browser. The browser checks theheader for the HTTP response code and for a new cookie. If the response is OK, thecookie is stored, and the HTML content is parsed. The parsing process is CPU intensive.Part of the parsing process is to determine the number and size of any inline images inthe document. Separate requests will be made for these images. Finally if the requesteddocument is a HTML page, it is layed out and displayed.

For overall browser performance, basic recommendations include only checking thecache one per session (or never) and getting the latest version of the browser forHTTP/1.1 support.

The most common browsers are Internet Explorer and Netscape. Lynx is a text basedbrowser, often used when working on a command line terminal (such as unix).

Checkpoint

1. The RAM is the most ciritical piece of hardware on the web server machine. Why?2. Which protocols on the TCP/IP stack does a web browser directly access?

Performance Factors Network Performance Factors



COSC1300

Client Performance Factors Server Performance Factors

3.2 Network Performance Factors

n this chapter, we examine the network factors thataffect the performance of retrieving a web document

from a server.

Table Of Contents


Hardware

At the IP layer of the TCP/IP model, the connection between a client and a server isdirect. But in reality, all data that is transmitted must pass through a series of networks.IP is responsible for transmitting data one network at a time.

Between hosts are lines, and between networks are routers. There are many differenttypes of network hardware that exist, and the variation in quality and type affects thetime it takes for data to travel between the client and server.

Lines

A line is a connection between two points. Every connection on the Internet is made outof a physical line which may be constructed of metal, fibre optics, or even space. At theend of each line is a terminator.

The latency of the Internet is not due to the lines which have a maximum speed of thatof light, but due to the terminators at each end of lines, typically a router or modem. Theideal situation is to have as few terminators as possible between the client and server.

Router

Routers connect two networks, forwarding data between them. Because a router mustexamine each packet of data it receives to determine where to send it, significant latency

is generated at the router.

Modem

Modems are used to connect a PC to the standard telephone line (Plain Old TelephoneService, or POTS). Most users on the Internet connect through a modem (althoughbroadband connections, for example ADSL or cable are becoming more popular).

The telephone system (by which telephone offices where switching takes place)transmits data digitally at a rate of 64kbps. However your local telephone connects tothe switch using POTS which sends data using an analog signal. So the data from yourcomputer, which is a digital signal, has to be translated into a analog signal by yourmodem, then translated into digital at the switch, translated back into an analog signal atyour ISP’s switch, and again, back into digital to reach your ISP’s computer. All thisconversion adds considerable latency. Also, the telephone system has a maximum rateof 64kbps. For connections to the Internet to be faster, they must bypass the telephonesystem altogether.

Modems are also responsible for data compression and providing a synchronousconnection, which helps reduce overheads.

Protocols

A protocol is a set of instructions, or rules, that allow consistent communication (in oneform or another). On the Internet, we use protocols for devices, such as computers, tocommunicate successfully. The value of a protocol is determined by the number ofpeople who use it, even if the protocol itself is not particularly efficient.

The important protocols of the Internet are the TCP/IP protocol suite, and the protocol tosend documents across the www is HTTP.

TCP

The Transmission Control Protocol was designed to establish a reliable "virtual"connection for IP packets. To achieve this requires considerable overhead because eachconnection must be established with a three-way handshake, and all data exchangedmust be acknowledged.

TCP was created based on the assumptions that connections would be madeinfrequently, on each connection a large amount of data would be transferred, and thecorrectness of the data was more important than performance. Unfortunately this isparticularly unsuited to HTTP messages which consist of many short-lived messages inrapid succession.

HTTP

HTTP was designed to transmit HTML documents across the Internet, although HTTP isnot limited to serving HTML documents. This is achieved in a straightforward manner -a client makes a request for a document and a server returns it.

The problem with HTTP is it was designed to serve static pages, and this makes it quite

unsuitable as a protocol for making transactions that require state to be maintained.Statelessness has the advantage of reducing the overhead of HTTP messages, but toimplement state, additional external methods (such as cookies) are required.

The transfer of data with HTTP is asymmetric. Requests are quite small compared to thedocuments retrieved. This means bottlenecks are more likely to occur on the serveroutput, than the server input.

HTTP and TCP are not as efficient as perhaps other protocols for transferring dataacross the Internet, and even though we have no choice but to use them, we shouldensure we use the latest version of both protocols. This is because as the protocols havematured, they have been updated to work more effectively with each other.

DNS

Domain Name Service, via a hierarchy of databases, is used to map IP addresses todomain names. This is required every time a user makes a request specifying a URLinstead of an IP address (nearly always!). DNS has the potential to be slow, so it doesnot have to be used. But the advantage of human readable URLs usually outweighs theperformance penalty of using DNS.

On Unix, DNS can be avoided by hardcoding the /etc/hosts file with IP addresses andtheir corresponding domain names. While this is efficient, it is quite limited, as theinformation in the /etc/hosts file is static, unlike DNS databases, which are updateddynamically.

Checkpoint

1. Why does your modem have to translate data from digital to analog and viceversa?

2. What happens if the nearest DNS server doesn’t have a mapping of the requesteddomain name to IP address?

Client Performance Factors Server Performance Factors



COSC1300

Network Performance Factors Apache Performance

3.3 Server Performance Factors

n this chapter, we examine the server itself forperformance factors.

Table Of Contents


Hardware

Many of the issues discussed under client hardware are relevant to the server. But aserver is not like a client. A client machine will typically be running many softwareprograms, and needs only to run a browser to connect to the Internet. A server, on theother hand, should only ever run the software that is absolutely necessary. The needs ofthe server machine will also differ to the client hardware because the server must dealwith many requests at one time.

Essentially a web server is a location that stores documents remotely. Upon request, itserves documents from its memory or disk to its connection to the network. So in termsof hardware, a server can be quite simple: it doesn’t necessarily need a mouse, akeyboard or a monitor. And it certainly doesn’t need a window-style display system.Web server admin can be done remotely with a telnet session.

Memory

To reduce accesses to disk a server should ideally have enough RAM to store all of thestatic web documents in cache (if that is reasonable).

Network Interface Card

The network interface card (NIC) provides the interface between the network and theserver machine’s bus. Traditionally, data on the network moved much slower than data

on the computer, but this may no longer be the case on local area networks (LAN).

The NIC provides a buffer which, typically, holds information from the computer, untilthe network is ready for it. This may be reversed on computers attached to fast LAN.The larger the buffer the better, to prevent buffer overflow, and therefore the loss ofdata.

Disk Drives

The speed of the hard disk could be a major bottleneck in server performance. If accessto the hard disk can’t be avoided, then the hard disk should be as fast as possible.Traditionally SCSI disk drives were the fastest type of drive, but recently EIDE drivesare approaching or equalling the speed of SCSI disks without the substantial cost.

Operating System

There are two realistic options for web server operating systems (OS) - Unix (or a Unixvariant) and Windows NT (or Windows 2000 which is based on Windows NT).

Unix

Unix uses processes to do work where each process is independent and unique. Unix ismulti-user and multi-tasking, so many processes belonging to many users can run at onetime.

Unix uses a kernel to control fundamental OS functions, like interfacing to hardware andhandling scheduling the processes of the users.

For Apache, a master process (called httpd) runs with root permissions, listening to port80 for incoming requests. When a request arrives, the master httpd process hands therequest to a child httpd process (with nobody permissions) to deal with it. In terms ofperformance, the master httpd process must wait for kernel processes (which have ahigher priority), and share whatever CPU time is left over with other user processes.Therefore it is critical to minimise the number of non-essential user processes withwhich the httpd process has to share CPU time.

Windows NT

Windows NT has the advantage that it is closely tied with other Microsoft software, ithas a consistent look and feel, and provides a graphical interface for controlling the webserver.

However Windows NT is not especially good as a web server OS. It does not have agood performance, it is unstable compared to Unix, and it does not scale well.

Software

Web servers take requests from clients and return a response. The reply could be theresource the client requested, either a static or dynamically generated page, or an error.When a web server is lightly loaded, it is more likely that the performance bottleneckwill be in the modem or the Internet. However the performance of a web server tends to

degrade in a non-linear fashion under heavy load.

Therefore it is important that web servers are tuned for optimum performance.

Content

The basic performance principle is to send less data which will translate into less timethe user has to wait. Content creators should be aware of good page design. Simplelayout, minimal graphics and in the correct format, the use of cascading style sheets, allfor the benefit of sending less data.

Checkpoint

1. Tests have shown that NT and linux have a similar performance as operatingsystems for web servers. What is the advantage of Linux and Apache over NT andIIS?

Network Performance Factors Apache Performance



COSC1300

Server Performance Factors Server Clusters

4. Apache Performance

n this section we discuss configuration options that canbe used to improve the server performance of Apache.

Table Of Contents


Improving Apache Server’s Performance

When we discussed the installation and configuration of the Apache server, wementioned that there are a few directives that can be tinkered with, to get the bestperformance from your Apache web server. In this section, we discuss these directivesin detail.

Apache defines several directives that are directly related to performance, controllingthe operation of the server at the process and protocol level. In addition, there are someother Apache directives not directly related to the server performance that can haveeither a positive or negative effect on performance, depending on how they are defined.

We will also look at Multi-Processing Modules (MPMs). These are new to Apache 2.0and define the way Apache works. The performance directives are specific to whicheverMPM Apache 2.0 is configured with.

However, there are limitations. Eventually, a point is reached where no improvementscan be gained by tuning these parameters. When this point is reached, there are twopossible solutions: migrate to more powerful hardware, or add more servers and create acluster. We’ll discuss how a cluster of servers can be set up in the next section.

Apache’s Performance Directives

Apache performance basically fall into two broad categories.

Protocol-level directives that control how Apache manages the connection with aclient. Process-level directives that control the number of processes that Apache servermaintained as a pool to handle incoming requests.

Protocol-level Performance Directives

In addition to controlling the server pool, Apache also provides some directives tocontrol performance-related issues at the TCP/IP and HTTP levels. These are platformindependent; they work regardless of the platform Apache is running on.

SendBuffers <bytes>

This directive determines the size of the output buffer used in TCP/IP connections and isprimarily useful for queuing data for connections where the latency (the time taken for apacket to get to the remote end and for the acknowledgment message to come back) ishigh. For example 32kb buffers can be created with

SendBufferSize 32768

KeepAlive <on|off>

This directive enables persistent connections. In HTTP/1.1 this is the default mode ofconnections. However, there are a few reasons to disable it in certain cases. Forexample, some old browsers do not support this type of connections, in which case, it isa resource waste to keep persistent connections.

KeepAliveTimeout <seconds>

This directive specifies the amount of time an Apache process will wait for a client toissue another request before closing the connection and returning to general service.This should be a relatively short value, for example 15 seconds. If this time is not longenough for the clients’ next request, the persistent connection drops and a newconnection must be established. In other words, we lose the advantages of persistentconnection. On the other hand, if it is too long and the server receives many requestsfrom other clients, we waste resources by keeping this connection reserved, waiting tillthe original client calls again.

MaxKeepAliveRequests <number>

This is similar to the MaxRequestsPerChild directive, and is used to limit the numberof serves per persistent connection. The server will automatically terminate thepersistent connection when the number of requests specified byMaxKeepAliveRequests is reached. In order to maintain the server performance, thisvalue should be kept high, and the default is accordingly 100.

This directive is important, not only for performance tuning, but for server security aswell. If a malicious client exploits a persistent connection by sending continuousrequests, it may cause a ‘‘denial-of-service’’ of the server. Such an attack can be

avoided by using the above directive.

TimeOut

This directive determines how long Apache server will allow an HTTP connection toremain when it becomes inactive. This is determined by the following criteria:

the time between a connection being established and a GET request beingreceived. the time since the last packet of data was received on a PUT request. the time since the last acknowledgment response was received.

Other Configuration Options for Better Performance

In addition to the above mentioned performance tuning on the Apache server, there are afew other adjustments we can make to improve its performance.

Cancel DNS and Host Name Lookups - Use the HostNameLookups off directive that disables host name lookups andrecords IP addresses instead in the access logs. Enable Symbolic Links -Use Options FollowSymLinks directive so Apache does not have to check theentire path to see if any parent directories are symbolic links. It takes time forApache to check the permissions of every directory in the path. However allowingFollowSymLinks is the most permissive approach in terms of security. Minimize the use of images, and use them sensibly -For example, some web front-end designers use images to get special effects onfonts, which eventually become a bottleneck in your server performance.Do you want to deliver your information to 10 clients with all bells and whistles,or deliver to 1000 clients without unnecessary embellishments? Use Cascading Style Sheets (CSS) as far as possible -This will prune most of the design and presentation parts from your document andgeneralized CSS’s can be used for the entire site; this will indirectly help improvethe web server performance too. Minimize use of Secure Sockets Layer (SSL) -SSL, while bringing all-important security features into your web server, adds ahuge CPU overhead on to the server. SSL involves heavy integer calculations, andto deliver each page the web server need to repeat these lengthy calculations. The bottomline is use SSL only if it is really necessary.

Multi-Processing Modules (MPMs)

The basic way in which Apache 2.0 interacts with the operating system on which it isrunning, and the architecture that it employs, is determined by which MPM it isconfigured with when compiled.

There are a number of MPMs for different operating systems, including BeOS, OS/2,Unix, and Windows NT. We will be looking at the MPMs for Unix (and Linux) andWindows NT. The specific MPMs we are interested in are:

prefork

worker mpm_winnt

Prefork and worker are for Unix, and mpm_winnt is, obviously, for Windows NT.

Process-level Directives

StartServers (prefork, worker)

This determines the number of child processes Apache will create on the startup.However, since Apache controls the number of processes dynamically depending on theserver load, altering this directive does not have very much effect.

MinSpareServers (prefork)

This sets the minimum number of Apache processes that must be available at any time.If processes become busy with client requests, Apache will spawn new processes tokeep the pool of available servers at a minimum value. Raising this value is useful ifyour server expects frequent bursts of requests, and needs to serve such bursts rapidly.

MaxSpareServers (prefork)

This sets the maximum number of Apache processes that can be idle at one time; ifmany processes are started to handle a burst in demand and then the burst tails off, thisdirective will ensure that excessive processes will be killed. At fixed time intervals,current idle processes are counted, compared with this directive and extra servers arekilled. For a site with a million or more hits per day and experiences bursts of requests, areasonable value could be

MaxSpareServers 64

This directive ensures that the system is not overloaded by spare Apache processes, andis definitely useful if the computer running the web server is used for other purposes aswell.

MaxClients (prefork, worker)

This is the hard upper bound for the number of Apache processes that can ever bespawned, either to maintain the pool of spare servers or to handle sudden bursts ofrequests. Clients that try to connect when all processes are busy will get ServerUnavailable error message.Setting MaxClients lower helps to increase the performance of client requests thatsucceed, at the cost of causing some client requests to fail. It must therefore be tunedcarefully; If settling for a compromise seems difficult, it indicates the server either needsto be tuned for performance elsewhere, upgraded, or clustered.

For prefork this is the total number of child processes. For worker this is a product ofthe total number of child processes by the ThreadsPerChild directive, which should bea multiple of ThreadsPerChild.

MaxRequestPerChild (prefork, worker, mpm_winnt)

This limits the maximum number of requests a given Apache process will handle beforevoluntarily terminating. The objective of this mechanism is to prevent memory leakscausing Apache to consume increasing amounts of memory. By default, this is set tozero, meaning that processes will never terminate themselves. A low value for thisdirective will cause performance problems as Apache will be frequently terminating andrestarting processes. A more reasonable value for platforms that have memory leakproblems is 1000.

For prefork this is the number of requests each process will serve. For worker andmpm_winnt this is the number of requests that the threads of a process will serve, intotal.

ThreadPerChild (worker, mpm_winnt)

This directive sets a static value for the number of threads created for each child process.For mpm_winnt there is only one process, therefore this value represents the totalnumber of servers, and should be set to deal with the maximum load. For worker thereare multiple processes, so this should be set to deal with a common, or average load.

MinSpareThreads (worker)

This sets the minimum number of Apache threads that must be available at any time. Ifthreads become busy with client requests, Apache will spawn a new process to keep thepool of available threads at least at the minimum value. It is usually unnessecary toadjust this directive

MaxSpareThreads (worker)

This sets the maximum number of Apache threads that can be idle at one time; if manyprocesses (and therefore threads) are started to handle a burst in demand and then theburst tails off, this directive will ensure that excessive threads will be killed. At fixedtime intervals, current idle threads are counted, compared with this directive and extraprocesses are killed.

Checkpoint

1. What are the major factors that could affect the performance of a heavily loadedweb server?

Server Performance Factors Server Clusters

COSC1300 - Lecture NotesWeb Servers and Web Technology

Copyright © 2000 RMIT Computer ScienceAll Rights Reserved

COSC1300

Apache Performance Web Caching

5. Web Server Clusters

n this section we discuss web performance from aserver administrator’s viewpoint.

Table Of Contents


If your server receives requests that can’t be handled just by tuning it for heavy loads,the next best alternative is to use better hardware. Then again, you may reach an upperbound that existing hardware (and the budget) can offer to your needs. If you still needhigher performance, then the next option is to install a web server cluster. In a webserver cluster, we distribute the load, as evenly as possible, between several servers.Some sophisticated mechanisms are required to set up such a server cluster. Inparticular, examining the access patterns for the site is crucial to the performance tuningand load balancing process.

There are a number of different ways to set up a server cluster. A few of the mostcommon methods are given below.

Load Balancing - DNS (Round-robin Type)

DNS balancing is one of the easiest ways to create a Web site that can handle more hits.It basically involves having multiple copies of the site on separate physical servers.However, each server must be identical.

Then, the DNS server for the hostname of the site such as www.extropia.com is set up toreturn multiple IP addresses for the site. The DNS server can do this by either justreturning more than one IP address for the hostname or returning a different IP addressfor each DNS request it receives.

Either way, what happens is a very basic distribution across the Web servers, althoughas far as the Web browsers are concerned there is only one Web site. This balancing isvery basic, however, as it is difficult to determine to which IP address each client willresolve the site name. Also, since DNS query answers are essentially cached by theclients and other DNS servers, that single client will continue accessing the same Webserver for the duration of the user’s visit.

It is possible then that through luck of the draw, heavy Web site users may get one IPaddress, and less-frequent Web site users tend to get another IP address. Thus, even withthis load-balancing technique in effect, it is possible that the Web server correspondingto the first IP address will be highly loaded, and the other one will be lightly loaded,rather than having the load spread evenly between the two.

Unfortunately, the problems with this sort of ‘‘poor-man’s load balancing’’ do not stophere. DNS caches may not stay alive forever. So it is possible that a client, while using aWeb site, may end up receiving a different IP address for the Web site. This can causeproblems with dynamic sites, particularly ones that need to store data about the client.

Since it is possible for a single client to hit more than one of the Web servers, this dataneeds to be shared across all of them. Depending on how complex the data is, it may bea nontrivial programming task to get the data shared uniformly in real-time amongst allthe Web servers.

Load Balancing -- Software/Hardware

Software and hardware load balancing is similar to the DNS method just discussed, butrather than having the client attempting to access multiple IP addresses, only one ispublished. A machine is then set up to intercept HTTP requests to this one IP addressand distribute them among the multiple servers hosting the Web site. Usually thisdistribution occurs at the level of TCP/IP routing which transparently maps a singlesource/destination IP address to a particular Web server in the Web farm.

This can be done with both hardware or software, with hardware solutions generallybeing more robust, but of course more expensive. The balancing this achieves is usuallymuch better than the DNS method, as the load balancer can distribute the requests moreevenly across the Web servers.

In addition to these, this type of load balancers typically detect when a Web server in thepool has gone down, and can dynamically redirect the request to an identical Webserver. With DNS load balancing, the client is stuck with a cached IP address of adowned Web server and cannot be redirected to a new one until the Web browser canrequest another IP address from the DNS server.

6. Links

Apache Tomcat Server (for Java)Everything you wanted to know about CGIPHP usage statsMore PHP usage statsNetcraft web server usage surveyWebstone Benchmarking SoftwareSPECWeb Benchmarking SoftwareW3C paper on Network Performance Effects of HTTP/1.1, CSS1, and PNGA comprehensive directory of Web Site management tools

7. References

Web Protocols and Practice, B. Krishnamurthy and J. Rexford, Addison-Wesley, 2001.

Apache Performance Web Caching

COSC1300 - Lecture Notes Web Servers andWeb Technology

Copyright © 2000 RMIT ComputerScience

All Rights Reserved

Chapter 5

Documents

Transcript of Chapter 5