Fork-exec model Server Architecture Models Operating Systems - PDF document

Fork-exec model Server Architecture Models Operating Systems Hebrew University Spring 2004 Server Behavior Drawbacks 1. This multiprocessing architecture is useful if the handling of the client request takes some time or a session state has to be kept by the (child) server 2. HTTP, however, is a stateless protocol. No session information needs to be kept by the server 3. An HTTP server based on that architecture would be inefficient – The master server would have to create a process for each HTTP connection, which would handle this one connection only and then die – While the master server creates a process it cannot accept incoming requests – a bottleneck for the entire server. Pre-Forking Model – Win32/WinNt MPM The leader-followers pattern • Uses threads (a lot more performant than Win processes) The preforking architecture is based on a pool of tasks – The number of threads is fixed, since idle threads impose almost (processes or threads) no performance issue which are playing 3 different • There are two Windows processes in this roles: multitasking architecture: • wait for requests (listener) • process a request (worker) – At restart, the master process creates the child process • queue in and wait to – The worker process (child server process) contains the threads become the listener (idle which handle the requests, worker) – while the supervisor process (master process) makes sure that • The listener is the leader, the worker process works correctly the idle workers are the – For connection distribution to the workers a job queue is used followers 1

Win32/WinNt MPM Win32/WinNt MPM cont. • The master-child connection is done via events – master to child: shutdown, restart – child to master: need restart, error that requires shutdown • Worker process’ threads: – master thread – starts one or multiple listeners – listener(s) thread(s) – accept requests and put into the job queue – worker threads – read from the queue and handle requests (by calling some routine) MPM for Linux/Unix cont. MPM for Linux/Unix • Combine a multiprocessing and a • Within each child process, the multithreading model: communication between the listener and all – a variable number of processes, which include a worker threads is organized with two fixed number of threads queues: – pre-forking model on process level and job queue – the job queue model on thread level – the idle queue – each child process incorporates a listener thread • Advantages of this approach are that it • The master server creates the child combines: process, which starts a starter thread that – the stability of multiprocessing set up all worker threads and a single – the high performance of multithreading listener thread Thread Pool MPM for Linux/Unix 1. Create a number of threads at process startup and place them into a pool where they sit and wait for work. • e.g. for multithreading a web server. 2. A thread from the pool is activated on the request, and it returns to the pool on completion. 3. Benefits of thread pool: – Faster service – Limitation on the number of threads, according to the need. 4. Thread-pool-architecture allows dynamic adjustment pool size. 2

Thread Pool Model for Ex4 Thread Pool Model for Ex4 • From the exercise definition: Build a multithreaded server. computation The main thread will handle user input, output thread thread input second thread will handle load balancing user Main thread computation between computation threads, additional thread balancing three threads will be used to compute thread computation thread prime numbers, and the last thread will handle all output. mutex locks thread creation int pthread_create(pthread_t *thread, pthread_attr_t *attr, int pthread_mutex_lock(pthread_mutex_t *mutex); void* (*start_routine)(void*), void *arg); – blocks until the mutex is free, and than locks it thread – pointer to the new thread int pthread_mutex_trylock(pthread_mutex_t *mutex); attr – the new thread attributes, usually NULL (i.e. system – fails if the mutex is already locked, otherwise – locks it thread that we can do ‘join’ on it = wait to his end). int pthread_mutex_unlock(pthread_mutex_t *mutex); start_routine – pointer to the function that is the thread – frees (unlocks) the mutex code, the return value of that function is the end value of the thread arg – parameter for the start_routine function Event-driven cont. Event-driven • The main program creates acceptors. • Advantages: • Each acceptor creates event-handler for – services can run independently each event it is interested in, and the – integrating new services is easy – a programmer can do his own ‘task management’ and handler registers for this event. save context switching (context is saved in the data • The main program listens for events. structure) • Drawbacks: • When event occurs, the appropriate – resource management problems if requests arrive acceptor is notified, notify the handler, faster than they are processed which handle the event. – big overhead for system with short-duration services – harder to implement than other models 3

References Apache Modeling Portal http://apache.hpi.uni-potsdam.de/document/4_3Multitasking_server.html Efficient Architectures for object-oriented component based Middleware http://www.stal.de 4