Server Architecture Models Operating Systems Hebrew University Spring 2004

Fork-exec model

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 – The leader-followers pattern The preforking architecture is based on a pool of tasks (processes or threads) which are playing 3 different roles: wait for requests (listener) process a request (worker) queue in and wait to become the listener (idle worker) The listener is the leader, the idle workers are the followers

Win32/WinNt MPM Uses threads (a lot more performant than Win processes) –The number of threads is fixed, since idle threads impose almost no performance issue There are two Windows processes in this multitasking architecture: –At restart, the master process creates the child process –The worker process (child server process) contains the threads which handle the requests, –while the supervisor process (master process) makes sure that the worker process works correctly –For connection distribution to the workers a job queue is used

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)

Win32/WinNt MPM

MPM for Linux/Unix Combine a multiprocessing and a multithreading model: –a variable number of processes, which include a fixed number of threads –pre-forking model on process level and job queue model on thread level –each child process incorporates a listener thread The master server creates the child process, which starts a starter thread that set up all worker threads and a single listener thread

MPM for Linux/Unix cont. Within each child process, the communication between the listener and all worker threads is organized with two queues: –the job queue –the idle queue Advantages of this approach are that it combines: –the stability of multiprocessing –the high performance of multithreading

MPM for Linux/Unix

Thread Pool 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.

Thread Pool Model for Ex4 From the exercise definition: Build a multithreaded server. The main thread will handle user input, second thread will handle load balancing between computation threads, additional three threads will be used to compute prime numbers, and the last thread will handle all output.

Thread Pool Model for Ex4 user output thread Main thread computation thread balancing thread input computation thread

thread creation int pthread_create(pthread_t *thread, pthread_attr_t *attr, void* (*start_routine)(void*), void *arg); thread – pointer to the new thread attr – the new thread attributes, usually NULL (i.e. system thread that we can do ‘join’ on it = wait to his end). start_routine – pointer to the function that is the thread code, the return value of that function is the end value of the thread arg – parameter for the start_routine function

mutex locks int pthread_mutex_lock(pthread_mutex_t *mutex); –blocks until the mutex is free, and than locks it int pthread_mutex_trylock(pthread_mutex_t *mutex); –fails if the mutex is already locked, otherwise – locks it int pthread_mutex_unlock(pthread_mutex_t *mutex); –frees (unlocks) the mutex

Event-driven The main program creates acceptors. Each acceptor creates event-handler for each event it is interested in, and the handler registers for this event. The main program listens for events. When event occurs, the appropriate acceptor is notified, notify the handler, which handle the event.

Event-driven cont. Advantages: –services can run independently –integrating new services is easy –a programmer can do his own ‘task management’ and save context switching (context is saved in the data structure) Drawbacks: –resource management problems if requests arrive faster than they are processed –big overhead for system with short-duration services –harder to implement than other models

References Apache Modeling Portal Efficient Architectures for object-oriented component based Middleware