Lecture Notes for Client-Server Interfaces
20 March 2001 - Server Concurrency
- to be, or to are - that is the question
- iteration or concurrency
- an early design decision, expensive to redo once done
- influences design, implementation, performance
- depends on expected load, software, hardware, and networking
technologies - all only temporarily stable
- concurrency can improve availablity, performance, and security
- design techniques
- delay decisions as long as possible
- no decision is final
- concurrency levels - number of computations
- constant or variable number of computations - long term and extreme
behavior is important
- unbounded concurrency is bounded by other resources - connections,
processes, cpu cycles
- banging up against resource limimts can be rude and dangerous, or it
can be a design feature
- demand driven concurrency - the longest delay possible
- concurrency costs
- creating and deleting new computations
- computation management should not exceed request processing time
- periods of high demand
- constant concurrency levels - fixed number of computations
- small, constant overhead amortized over many requests
- some coordination overhead between listener and workers
- long-lived computations are less forgiving than short-lived ones -
storage leaks
- listener-worker coordination
- shared listen socket - fork workers; need mutual exclusion on the
socket; the listener doesn't do much
- trickier without listen-socket mutex semantics - implement mutual
exclusion; have the listener broker
- connectionless preallocation - similar to connection-oriented; useful
for improving best-effort datagram services
- pre-allocation and true concurrency - eliminat scheduling overhead
- iterative-concurrent servers - handle variable requests
- service time may be non-constant and difficult to determine
- iteration needs short service times, concurrency needs long service
times - any particular request may be either
- start iteratively, then go concurrent after some period of time
- can be expensive, can be tricky
- delay the concurrency-level decision
- reducing concurrency by harvesting workers
- recover resources; refresh workers;
- a function of idle time, time of day
This page last modified on 19 March 2001.