The Fundamental Problem and Its Solution

The biggest problem with server applications is that we poor humans find it hard to truly visualize multiple things going on at the same time. Our brains organize linearly. To make our server debugging easier, we subconsciously gravitate toward ensuring that our tracing output is in linear time. However, with multiple processors being the norm on most servers these days and with many applications running with 20 or more threads, many of those linear universes are happening at the same time. In our effort to create order out of this seeming chaos, our tracing resorts to a single file responsible for reporting the whole application's tracing.

When you have a single file containing the tracing and a multithreaded application, you're looking at the situation described in Figure 18-1. The bottleneck comes from trying to make tracing calls from every thread linear. As I mentioned in Chapter 15, your whole job when it comes to multithreaded programming is to keep your threads as busy as possible and waiting as little as possible.

Figure 18-1: The common server tracing system

Obviously, taking the processing time necessary to keep things linear out of the normal execution is absolutely critical to having the fastest tracing in the West. If each thread did its own tracing, the situation would be perfect. Well, that's exactly what FastTrace does: it gives each thread its own tracing output file so that none of the threads are waiting or blocking. After the trace output for multiple threads has been saved to log files, you can merge these log files so that you can see the tracing as it exactly occurred. In the section titled "FastTrace Implementation" later in this chapter, you'll see that FastTrace is quite straightforward to implement.