Advanced ColdFusion 4 Application Development with CDROM

Read an Excerpt

Chapter 1: Monitoring Server Performance

Understanding Performance

Don't panic. The trick to solving your performance problem is to systematically analyze your site. Identify the individual components that make up your site, and examine them closely until you find the trouble spot-the bottleneck. After you find the bottleneck, you can either make that part of your site work better under load, or you can scale it-that is, add more server capacity to handle the extra stress caused by the traffic. This chapter will help you analyze your site for bottlenecks. The three chapters that follow will describe several ways you can scale your site, how ColdFusion can help you scale, and how to handle some of the challenges you'll face in building a ColdFusion site that has been scaled across multiple Web servers.

What We Talk About When We Talk About Performance

The terms I'm about to use and the model I'm going to present of Web server performance are not gospel. The model I'm using reflects my experience solving performance problems on many different Web sites, some with ColdFusion and some without and I'm confident that using this model will help you solve your own problems more quickly.

Your site's traffic is really just a series of requests. Answering a request uses some of your Web server's resources. Ibis is true for even the simplest Web hit-say, for a plain, old GIF file. When a user's browser requests that GIF, it takes server resources to listen for the request, acknowledge the request, allocate a HyperText Transfer Protocol (HTTP) server thread to handle the request, find the GIF file on disk, read the file, and pass the contents of the GIF back to the user's browser. As it happens, none of the steps required for handling a request for a GIF file take many resources, so well-written Web servers can handle very high numbers of requests for plain files. A request for a ColdFusion page is very different though, because it involves running ColdFusion Markup Language (CFML) code to produce a dynamic result If your CFML is complex, or if you're using all the other capabilities that make ColdFusion great - database calls, CFX tags, COM and CORBA objects, even additional HTTP requests with CFHTTP - a single ColdFusion page can become extremely resource-intensive.

When traffic is low, your site might receive only one request for a resource-intensive ColdFusion page at a time. If your server can devote its full attention to that one request, the response to the request is usually pretty fast, even if a lot of resources were consumed in generating the response. You see a performance problem only when traffic increases; because each request takes a lot of resources, your server can handle fewer resource-intensive requests at one time. As a result, your server takes more time to handle each request, and your site seems slower. And it gets worse. If a few resource-intensive requests are hogging your Web server's processing power, even simpler ColdFusion pages are slower to process. Resource-intensive pages can drag down your overall site performance even if they are only a small percentage of your total requests. When you have a situation like this, the piece of your system that is holding back overall performance is called a bottleneck.

Resource bottlenecks are not the only kinds of bottlenecks, but they are the type of bottleneck that you'll encounter most often with a ColdFusion Web site. They also are the type of bottleneck that scaling to multiple Web servers helps most directly.

N0TE: Another major source of bottlenecks is system limitations. If you are using a slow hard drive, the time that your server takes to read files could become a big bottleneck. Moving to faster SCSI drives, or even a RAID array, can help solve this bottleneck. If your Web server has to read large amounts of data from another machine on your network, you might need to move from 10BaseT to 100BaseT Ethernet connections. Because these bottlenecks are not Cold Fusion-specific, they're not addressed in this book, but you should examine all aspects of your site when analyzing a performance problem. If you don't, you could come to a very wrong conclusion. Jonathan once worked on a site that had a problem-users were constantly complaining that the site was too slow. After several weeks of poring over the source code to several dynamic parts of the site, the tech staff was at a loss. They hired a senior systems consultant to analyze the installation. The consultant quickly discovered that the system administrator hadn't installed several OS hotfixes related to networking. Installing the hotfixes increased the Web server's throughput by about 25 percent without changing any of the tech staffs code.

The Middleware Problem
I want to share a slightly uncomfortable truth with you: Middleware, defined as the application layer that sits behind a Web server and communicates with back-end services such as file systems, databases, and so on, has some built-in performance limitations that frequently require you to add more hardware than you might expect.

This problem is the result of a few different factors. First, most middleware (such as ColdFusion and ASP) is interpreted: To run your code, you just have to put it up on the site. You don't have a compilation step, such as for CFX tags programmed in C++ or Java servlets. An interpreted language is always slower than a compiled language; the interpreter (in this case, the ColdFusion service) is more resource-intensive because it has to keep the script interpreter in memory and use it frequently. With a compiled language, the interpretation happens at compile time, so the resulting DLL or executable doesn't have to devote resources to converting the code to machine language. The advantage of using interpreted languages is rapid development; writing C/C++ or Java code is much more time-consuming and is more difficult to change because you have to go back to the source code and recompile every time you want to make a change.

Middleware is also slow because it has to bridge the gaps between so many disparate systems. Web servers, file servers, and even database servers are much more "single-function" systems: They can focus on solving one problem very well and don't have to worry about the other pieces of the puzzle. These systems have been optimized to perform their single task extremely well. Middleware tools such as ColdFusion have to know how to speak with a multitude of different servers and protocols. It's a great advantage, but it carries a lot of overhead with it.

Finally, middleware is a very new segment of the software market. Commercial database servers such as Oracle, Sybase, and Microsoft SQL Server have been in development for years, constantly being tuned and tweaked for efficiency and speed. Middleware didn't really exist until early Web developers took a UNIX report-generating language (Perl) and started to use it to write CGI programs. ColdFusion's performance has improved with almost every release, and moving from ColdFusion 3. 1.1 to ColdFusion 4.0 will give you as much as a 30 to 40 percent performance enhancement. As the middleware market matures, products such as ColdFusion should improve until their performance characteristics are closer to that of database servers and other established server products.

Why does this matter? You need to attack your scalability problem with an understanding that your solution for a middleware product such as ColdFusion might seem less than elegant-buying more servers, changing functionality, even rewriting pieces of the site in CFX tags. If your boss gives you a problem, explain the middleware trade-offs reviewed here. If that approach doesn't work, sit with him or her for a few minutes and work out how much it would have cost if you wrote your entire ColdFusion application in raw C/C- code. I'm sure the exorbitant cost of such an effort will help your boss understand that a few thousand dollars for another ColdFusion server is a small price to pay in the grand scheme of things.

Monitoring Your ColdFusion Server

The best two places to find information about possible ColdFusion bottlenecks are the APPLICATION.LOG file and the Windows NT Performance Monitor. III talk briefly about the APPLICATION.LOG file and then focus on using the Performance Monitor (perfmon.exe) to watch your server's performance in real-time.

N0TE: Cold Fusion 4.0 uses different log files than ColdFusion 3.1.1 does. If you're using ColdFusion 3.1.1, look in the CFSERVER.LOG file instead of the APPLICATION.LOG file.

The APPLICATION.LOG File

The first performance-problem error is a Request timed out message. This error is written if a ColdFusion page takes longer to process than the timeout value you set in the ColdFusion Administrator. If your server is experiencing performance problems, some pages take so long to process that they trigger this error. It's a pretty crude filter; if you set your timeout value to 20 seconds, you have no way to know if the pages that aren't timing out are taking 5 seconds or 15 seconds to process. If you're getting Request timed out errors for only a few specific ColdFusion pages, odds are that those pages are at least one cause for your performance problems. If your Request timed out errors are spread evenly across most or all of the pages on your site, you might have a single bottleneck that is affecting everything. Does every page on your site query the same database? If this isn't the case, then you're already a strong candidate for scaling.

You can set ColdFusion 4.0 to log information about requests that take longer than a certain time to run. This capability is a big step forward over ColdFusion 3.1.1 because you don't have to wait for a page to actually time out to see that it's running slow.

Another performance-problem error reports that your ColdFusion page is a "deadlock victim." This means that a collision occurred while trying to read data from your database. Because this error is very specific to the database you are running, I won't talk about it here other than to point out what it means.

You can analyze your APPLICATION.LOG files Manually, just by reading them. I also recommend Ben Forta's handy <CFX_VIEWCFLOG> tag, which parses an APPLICATION.LOG file and writes the results into a ColdFusion query result set, suitable for further processing in a ColdFusion template. At SmartMoney Interactive, the staff used Ben's tag as the foundation for an automatic APPLICATION.LOG parser that lets developers request reports with the full text or summaries of ColdFusion errors matching specific text patterns.

The Windows NT Performance Monitor

perfmon Basics

perfmon is located under Administrative Tools in your Start menu. When you open perfmon, you see an empty workspace, as shown in Figure 1.1.

(FIGURE 1.1: This Windows NT Performance Monitor is not currently monitoring anything.)...

Read More