Server applications are basically processes listening on certain Layer 4 ports. Examples of applications/servers are web servers, common gateway interface (CGI) applications, Active Server Pages (ASP) servers, servlet engines, and so on.
Server implementations differ depending on how incoming connections are handled. A process can be spawned on a per-connection basis by another process listening on multiple ports (such as inetd in UNIX), or it can be a standalone server forking when new
connections arrive.
Example 2-11TFTP Transfer
13:05:30.433033 eth0 < 10.21.4.5.1026 > 10.20.5.14.tftp: 17 RRQ "IDS2.img"
13:05:30.481342 eth0 > 10.20.5.14.1274 > 10.21.4.5.1026: udp 516 13:05:30.481892 eth0 < 10.21.4.5.1026 > 10.20.5.14.1274: udp 4 13:05:30.481933 eth0 > 10.20.5.14.1274 > 10.21.4.5.1026: udp 516 13:05:30.482316 eth0 < 10.21.4.5.1026 > 10.20.5.14.1274: udp 4 13:05:30.482335 eth0 > 10.20.5.14.1274 > 10.21.4.5.1026: udp 516 13:05:30.482711 eth0 < 10.21.4.5.1026 > 10.20.5.14.1274: udp 4 13:05:30.482729 eth0 > 10.20.5.14.1274 > 10.21.4.5.1026: udp 516
Additionally, servers can be categorized as forking servers if they rely on creating different processes to serve new connections, or threaded servers if they rely on threads instead.
Example 2-12 shows the processes in a Linux system running an HTTP forking server.
When launching the web server, you have the root process and one child (process 31785).
In Example 2-12, you see a standalone implementation. The main process is like a supervisor to the activities of the other server processes and typically does not perform I/O operations.
NOTE Example 2-12 does not reflect the default settings of the HTTP server. Parameters have been changed to show the creation of new processes for new incoming connections. A regular web server configuration would create many more processes.
When one client sends a connection request, a new process is created, as you can see in Example 2-13. If the same client continues to open connections without closing them, new child processes are created to handle the new connections.
Threads are similar to processes, in that they allow concurrent operation, but they execute inside the same process and have less overhead than processes. Processes have separate memory space and file descriptors; threads are separate execution instances that share the same memory space. At a very high level, you can think of threads as separate program counters inside the same process.
If you executed the same tests as those in Examples 2-12 and 2-13 but used a threaded server, you would see a single process handling multiple connections.
Example 2-12Processes on a Standalone HTTP Server Before Receiving Clients’ Requests
[admin@localhost conf]# ps -ef | grep httpd
root 31784 1 0 21:44 ? 00:00:00 /usr/sbin/httpd httpserver 31785 31784 0 21:44 ? 00:00:00 /usr/sbin/httpd
Example 2-13HTTP Server Spawns a New Process to Serve a Client’s Request
[admin@localhost conf]# ps -ef | grep httpd
root 31784 1 0 21:44 ? 00:00:00 /usr/sbin/httpd -D HAVE_PERL httpserver 31785 31784 0 21:44 ? 00:00:00 /usr/sbin/httpd -D HAVE_PERL httpserver 31833 31784 0 21:46 ? 00:00:00 /usr/sbin/httpd -D HAVE_PERL
Server Availability 53
FastCGI is an example of a multiprocess application server. Servlet engines (which are basically Java Virtual Machines) are examples of threaded servers.
The main differences between forking servers and threaded servers are as follows:
•
Performance—Context switching between threads is much lighter than between processes, so the impact of an increasing number of connections on the CPU utilization is less with threaded servers than with forking servers. Because of this, threaded servers are more efficient than forking servers.•
Robustness—When you run an application inside a single process, the failure of one thread can affect the entire process and the other connections with it. A forking server is more robust because a main process does not deal with I/O operations. Additionally, this process periodically kills the child processes, which prevents memory leaks from crashing the server. If one child fails, other connections still succeed. As a result, forking servers are more robust than threaded servers.•
Shared state information—When dealing with a client that sends requests to the same application over a period of time, you typically want to save the session (state) information about this client. Processes do not share memory, which means that dispatching client’s connections to different processes forces the application developer to use temporary files or databases to save state information. Threads running in a single process share the memory space, which makes it possible to save the state information across multiple connections of the same application.Today’s servers can be forking, threaded, and hybrid. Hybrid servers keep a number of active processes for the same application and allow each process to serve a number of connections by using the threaded approach. You can make implementations of threaded servers more robust by launching several instances of them.
Multiprocess servers provide a solution to the need of sharing state information by writing this information on temporary files shared across servers or by using mechanisms such as session affinity.
FastCGI is an example of a multiprocess application server with session affinity. CGI initially had limitations related to the creation of a separate process for each connection request with performance and session state limitations. FastCGI solves the problem by providing the option of running as a multithreaded server or implementing session affinity.
(For more information about CGI, see Chapter 3.)
A robust application can be built by using multiprocess server and building multitier server farms. As an example, the business logic of the application can execute as a script in a different process than the web server. If the script has an infinite loop, the web server is unaffected. For more information about multitier architectures, see Chapter 3.