Chapter 7. Scalability and Multithreading As a server-side
Chapter 7. Scalability and Multithreading As a server-side programmer, my picture of the world is somewhat distorted by my experience. I have never worked on software that was single-threaded. Multithreaded design and implementation is the backbone of server-side programming, but they are definitely not limited to the server alone. Multithreading comes in handy on the client side as well. Why would you want to multithread your software? Three good reasons immediately come to mind: . Increased throughput . Reduced response time . Better CPU utilization Take a Web server, for example. Practically all of the dominant Web servers are multithreaded. Each incoming HTTP request is assigned to a server thread that will “escort” the request from its arrival until its departure in the form of a response. That thread could easily get blocked waiting on a page-fault, disk I/O (while reading a file), or socket I/O (waiting to receive data from a CGI script or a database.) If a Web-server thread gets blocked, there are usually plenty of other threads that can step up and continue serving other requests and keep the server cruising at full speed. This is where increased throughput comes into play on the server side. Multithreading also improves CPU utilization because there’s usually some thread ready to make productive use of the CPU. As mentioned earlier, multithreading is not limited to the server side; it also plays a major role on the client side. When you want to bail out of a very slow browser download, you hit the cancel button and the download aborts. If the browser is single-threaded, it isn’t very responsive. That single thread becomes tied up with the document download and ignores your plea to abort. Multithreaded programming is what makes the clients appear so responsive. Multithreaded programming has a special role in Java. When it comes to raw speed, Java programs are slower than C and C++ programs, and that is not going to change any time soon. In theory, you would expect this to be a show-stopper on the server side. In practice, however, Java is now carving itself a significant territory as a viable server-side programming language. This is not just because Java is so portable and its programmers so productive. It is also not because customers all of a sudden abandoned their obsession with performance. It is, to a large extent, because hardware is cheap and you could always throw in a 12-way SMP monster to elevate Java application performance to the required level. On the other hand, a powerful SMP machine does not guarantee improved performance. A serious programming challenge is still facing the Java developers: to design and implement our software in a scalable fashion. Faced with the task of speeding up a Java application, you generally have the following options: . Tune your application. Reduce the application’s pathlength by optimizing the code. This approach has been the focus of our discussion up to this point: speeding up a single thread of execution regardless of the underlying machine architecture (UP or SMP.) . Upgrade processing speed. A faster CPU should result in faster execution for CPU-bound workloads. . Add processors. A multiprocessor machine consists of multiple CPUs. In theory, multiple CPUs should outperform a single CPU of identical speed. This is what scalability is all about. The challenge in scalability for an application code is to keep up with the additional processing Page 144
Hint: This post is supported by Gama besplatan domen provider