Web Server Performance and Optimization Methods

1
Web Server Performance and Optimization Methods
Mi-Joung Choi DPNM Lab. Dept. of Computer
Science and Engineering POSTECH, Pohang
Korea Tel [phone] Email
mjchoi_at_postech.ac.kr
2
Contents

• References
• What is Web performance?
• Performance metrics of Web server
• How is performance measured?
• Benchmarking tool - WebStone
• Web server optimization
• Conclusions
• Open Issues

3
References

• James Rubarth-Lay, Keeping the 400lb. Gorilla at
  Bay Optimizing Web Performance, May 1996
• Robert E. McGrath, Measuring the Performance of
  HTTP Daemons, February 1996
• Robert E. McGrath, Performance of Several HTTP
  Daemons on an HP 735 Workstation, April 1995
• Robert E. McGrath, Performance of Several Web
  Server Platforms, January 1996
• Patrick Killelea, Web Performance Measurement,
  chapter 3 of Web performance tuning,
  http//www.patrick.net/wpt/
• WebStone, http//www.mindcraft.com/webstone/
• Fast Internet Agent, http//www.fiagent.com/

4
What is Web Performance?

• Parameters describing the performance of computer
  system latency, throughput, utilization, and
  efficiency
• Latency the time between making a request and
  beginning to see a result
• Throughput the number of items processed per
  time unit
• Utilization the fraction of capacity of a
  component that actually used
• Efficiency defined as throughput divided by
  utilization
• Web Performance ?
• Web retrieval time to client
• Processing capacity to server

5
Performance Metrics of Web Server

• Connections/second or requests/second is an
  important measure of the capacity of the Web
  server
• Throughput (bytes/second) is the total number of
  bytes transferred per unit time, which is
  dependent upon the bandwidth of the data pipe
• Round-trip time (RTT) or Response time is a
  measure of how long it takes for the server to
  complete a request
• Error rate is the measure of how may HTTP
  requests were lost or not handled by a server.

6
How is Performance Measured?

• Methods of measuring Web server performance
• Analysis of logs of active servers
• Benchmarking
• Components of Web benchmark
• The load generator (clients) mimics a stream of
  requests from web browser
• The workload(s) the stream of requests is
  called the workload, the load generator reads a
  configuration file that defines the workload
• The measurements and metrics the measured data
  are reported in the form of summary statistics,
  or metrics

7
Web Benchmarking Tool

• WebStone
• Silicon Graphics, Inc. developed
• Mindcraft, Inc. enhances WebStone2.0.1 to
  WebStone2.5
• Metrics avg. and max. connect time, avg. and
  max. response time, data throughput rate, of
  pages retrieved, of files retrieved
• Configuration parameters duration of test,
  repetition test, of files, of pages, of
  Webchildren, of networks, of clients,
  workload of pages

8
Web Server Optimization (1)

• Use standalone server daemon not inetd
• Condition NCSA 1.4 httpd, HP 735 system(HPUX
  9.05), small file (100bytes)

• Results
• Using inetd seriously reduce performance of Web
  server
• Using a small file, so the network transfer time
  is negligible
• Overhead incurred by using inetd daemon
• The inetd must fork() and exec() the HTTP daemon
  for each request
• The HTTP daemon must build its executable image,
  and read all its configuration for each request,
  rather than once at boot time

9
Web Server Optimization (2)

• Use threads or process pools not fork/exec
• Web server process model
• One process per request
• A dispatcher and a pool of helper processes
• A multithreaded server one process with one
  thread per request
• Condition NCSA 1.4 httpd, HP 735 system (HPUX
  9.05), file size(small-100bytes, typical-10KB,
  large-100KB)

10
Process Pools versus Fork (1)

• Direct measurement of startup costs
• Condition NCSA 1.4 httpd, HP 735 system (HPUX
  9.05), small file (100bytes)
• of fork time in RTT fork time(ms)/median
  RTT(ms)
• Fork time 6.9 ms, median RTT 16 ms, ?43
• Startup time(ms)
• Process pool 1.5ms, fork() 6.9ms

• Results
• The use of helper processes in pools to service
  TCP connections greatly reduces the overhead
  involved in forking a separate process
• Dispatcher/helper process architecture may have
  weaknesses

11
Process Pools versus Fork (2)

• Weakness of the dispatcher/helper process
  architecture
• The dispatcher is an obvious bottleneck
• What to do if all the helper process in pools are
  busy
• Start an additional helper process and dispatcher
  the request to it
• Queue the request until a helper process in pool
  is available
• Drop request
• Dropping the request is obviously to be avoided
  if possible
• Queuing the requests adds considerable
  complexity to the dispatcher
• Helper processes use up memory operating
  system resources when not serving requests
• Determine a good the of helper processes in
  pools by taking a tuning
• Threads take little resources and faster to
  start than process

12
Web Server Optimization (3)

• Use APIs in lieu of CGIs
• To extend a servers functionality, using an API
  instead of CGI eliminates the need to go to the
  OS for communications between the server and the
  script
• Use clusters of servers and a DNS distributor
  scalable Web server
• Use load distribution across a multi-server
  configuration
• Use a hierarchical Internet object cache proxy
  servers

13
Web Server Optimization (4)

• Other web server performance considerations
• Hardware platform and its subsystems CPU, RAM,
  disk I/O and file cache, network I/O
• Increase the RAM and file cache size
• Install the largest, fastest drives possible
• Increase the listen queue length
• Increase the retransmission delay if the clients
  have slow or error-prone connections
• Reduce logging to just those statistics required
  for proper monitoring of the server system

14
Conclusions

• Metrics Connections/second or requests/second,
  Throughput (bytes/second), Round-trip time (RTT)
  or Response time, Error rate
• Web server performance optimization
• Use standalone server daemon
• Use threads or process pools
• Use APIs instead of CGI
• Use a scalable Web server architecture
• Use a hierarchy of caching proxy servers
• Etc

15
Open Issues (1)

• The benchmarking packages provide mechanisms to
  examine the performance of Web server
• There are open issues due to using benchmarks
• The development and validation of workloads how
  relevant are the benchmark results to real
  performance of Web server
• Should examine the impact of scripts and other
  server-side programs
• The analysis of protocol extensions and options
  such as Web security(access control)

16
Open Issues (2)

• How can we optimize Web performance?
• Current methods of increasing Web performance
• Clusters of Web servers
• Web caches
• Modify protocol
• Fast Internet Agent reduce transmitted data