(RPM) Understanding the performance of fastcgi applications

from grasshopper Long blog turned over, as if he is also turning to other places, things are good, and recently do fcgi often encounter problems, see everyone's discussion, understand. understand the performance of fastcgi applicationsMark R. Brown.
Open Market, Inc.

June 10, 1996 copyright©1996 Open Market, Inc. 245, Cambridge, MA 02142 U.S.A.
tel:617-621-9500 fax:617-621-1703 url:http://www.openmarket.com/
$Id: fcgi-perf.htm,v 1.4 2002/02/25 00:42:59 robs Exp $
1. Introduction 2 Performance elements 3. Caching Technology 4. Database access 5. Performance Test 5.1 Application Overview 5.2 Application Design 5.3 test conditions 5.4 Test results and discussion 6. Multithreading API 7. Summary 1. Introduction

FastCGI is a lot of pieces. How to compare the performance of fastcgi applications with the same applications implemented using Web server APIs.

The answer, of course, is that it depends on the application. The more complete answer is that fastcgi often win with a big gap and rarely lose much.

A paper on the performance of a computer system may be full of complex graphs showing how this changes with that. It's rare to make a chart that focuses on why one system is faster than another. The promotional materials provide less information. Ads from a large Web server manufacturer say its server "executes Web applications 5 times times faster than all other servers", but the number of "5" sources that the ads offer is small.

This article intends to present an understanding of the main factors that affect the performance of Web service applications, and to demonstrate that architectural differences between FASTCGI and server APIs often give fastcgi applications an "unfair" performance advantage. We run a test that shows that the fastcgi application runs 3 times times faster than the corresponding Web server API application. If the conditions are different, the coefficients may be larger or smaller. We show you how to estimate the situation you are facing, what you need to weigh, rather than just say "we're 3 times times faster" and move on. Measure

This article does not intend to prove that fastcgi is better than the Web server API for each application. The Web Server API allows lightweight protocol extensions, such as the Open market Security link (securelink) extension, to be added to the Web server, and to allow other server customization forms. However, because of the disadvantages of high complexity, low security, and limited scalability, APIs are not suitable for mainstream applications, such as private content or access to commercial (corporate) databases. FastCGI wins on most web apps. 2. Performance Elements

Now that this article is about performance, we need to be clear about what "performance" is.

A standard way to measure the performance of a request-response system like the web is to measure the peak of request throughput within a defined response time. For example, a Web server application might execute 20 requests per second in 2 seconds and respond to a 20% request.

Measuring response times on the web is difficult because client traffic linked to the Internet has a large number of different bandwidths. If the response from the client Read server is slow, the response time on the client and server will grow, and the server can do nothing about it. For the purpose of making repeatable metrics, the client-server communication links should have high bandwidth.

[Footnote: When designing Web server applications that will be accessed through slow-speed (for example, 14.1 or 28.8kb/s cats), be aware of bottlenecks in the same line. Some servers deliberately limit the simultaneous presence of 100 or 200 lines. If your application sends 50KB data to a client that typically reads 2KB per second, then a request completes in 25 seconds. If your server is limited to 100 simultaneous lines, throughput is limited to 4 requests per second. ]

Response time rarely poses a problem when the load is light, but the response time increases rapidly when the system approaches the bottleneck on some limited resources. The three typical types of resources that the system runs out are network I/O, disk I/O, and processor time. If the short response time is a goal, it is a good idea to keep each of these resources at or below 50%. For example, if your disk subsystem can provide 200 I/O per second, try to have the system run at 100 I/O per second to avoid the disk subsystem slowing down response time. Careful management may succeed in getting the operation closer to the boundary, but it is carefully managed and costly, so that few systems can do so.

If the Web server application is local to the Web server machine, its internal design does not affect network I/O. Application design can significantly affect disk I/O and processor Time usage. 3. Caching Technology

When all the information required is available in its memory, it is rare for Web server applications to run quickly. And if the application does not run quickly under those conditions, it is clear that the solution is to adjust the portion of the application-consuming processor (processor-hungry), install a faster processor, or change the application's functional specification (functional specification) So that it does not need to do so many operations.

The way to make information available in memory is through caching techniques. Caching is an in-memory data structure that contains data that is read from the persistent origin (home) of information on disk. When the application requires information, it looks at the cache, if it is used. Otherwise, the information is read from the disk and a copy is placed in the cache. If the cache is full, the application discards some old ones before adding new data. When the application needs to change the cached information, it changes the cached entries and the information on the disk. That way, if the application crashes, the information is not lost, and the application is slower to run after a reboot, because the cache does not improve performance.

Caching technology reduces disk I/O and processor time because reading information from disk takes up more processor time than reading from the cache. With focus on two potential bottlenecks, caching technology is the focus of High-performance Web server application design. CGI applications do not perform memory caching techniques (in-memory caching) because they exit with only one request. The Web Server API promises to fix the problem. But what kind of solution works.

The most widely deployed Web server APIs today are based on the thread pool server model. The Web server consists of a parent process and a pool process. The process does not share memory. The incoming request is randomly assigned to an idle child (process). The child (process) runs the request to completion before accepting a new request. A typical server has 32 child processes, and a large server has 100 or 200.

Memory caching techniques work poorly in this server model because processes do not share memory, and incoming requests are randomly assigned to the process. For example, to maintain frequently used files in memory, the server must maintain a copy of the file for each child (process), which wastes memory. It is complex to notify all children (processes) When a file is modified (the API does not provide that functionality).

FASTCGI is designed to allow efficient memory caching techniques. Requests are routed from any child process to a FASTCGI application server. The FASTCGI application process maintains a memory cache.

In some cases, a single fastcgi application server does not provide sufficient performance. FASTCGI offers two solutions: conversational Affinity (Session affinity, also known as sticky sessions) and multi-threaded technology.

You run a pool of application processes with session affinity, and the Web server routes requests to private processes based on any information contained in the request. For example, a server can be routed according to the content area being requested, or based on the user. The user may be applied to a specific session identifier identifier, or the user ID contained in the Open Market Security link label (secure link ticket), or the Basic authentication (base authentication) Username, or something else. Each process maintains its own cache, and session affinity ensures that each incoming request has access to the cache, which greatly accelerates processing.

You run an application process using multithreading, which is designed to handle multiple requests at the same time. Threads that handle concurrent requests share process memory, so they all have access to the same cache. Multithreaded programming is complex-concurrency makes it difficult to test and debug-but with fastcgi you can write single-threaded or multi-threaded applications. 4. Database Access

Many Web server applications perform database access. The existing database contains a lot of valuable information; Web server applications allow companies to access this information extensively.

Access to the database management system, even within a single machine, is through a connection-oriented protocol. Apply the Enter database, create the connection, and then perform one or more accesses. The cost of creating a database connection is often several times that of accessing data through an established connection.

For the first approximation, the database connection is just another type of state that is to be applied to the cache in memory, so the above caching technique applies to caching the database connection (apply to).

But database connections are special in some ways: they are usually the primary basis for database licensing. You pay the database vendor according to the number of concurrent connections that the database system can support. 100 the license for a connection costs more than 5 connections. It can be concluded that each Web server subprocess caches a database connection that not only wastes system hardware resources, but may also exceed your budget. 5. Performance Test

We have designed a test application to illustrate performance issues. The application represents a class of applications that provide private content. Test applications are much simpler than any real-world application, but still illustrate the main performance issues. We implemented the application using FASTCGI and the current Web server APIs, and measured each performance. 5.1 Application Overview

Applications are based on a user database and a set of content files. When a user requests a content file, the application executes the substitution in the file with information from the user's database. Then the application returns the modified content to the user.

Each request completes the following: Authentication check: The user ID is used to retrieve and verify the password. Property retrieval: The user ID is used to retrieve all of the user's property values. File retrieval and filtering: Request identification of a content file. The file is read and the variable name that appears is replaced with the corresponding property value of the user. The changed HTML is returned to the user.

Of course, this is a fair game that performs caching to simplify any one of these steps.

Database records for each user, including passwords and property values, are approximately 100 bytes long. Each content file is 3,000 bytes long. Both the database and the content files are stored on the disk that is placed on the server platform.

A typical user makes 10 file visits at a thought time (30-60 seconds) between each access interval, and then disappears for a long time. 5.2 Application Design

FastCGI applies a cache that maintains the most recently accessed property values from the database. When the cache is missing, the application reads from the database. Because only a small number of fastcgi application processes are required, each process starts with a database connection open and remains open.

FASTCGI applications are configured as multiple application processes. This is worthwhile in order to get concurrent application processing during database reading and file reading. Using FASTCGI's user ID as the key for session affinity, requests are routed to these application processes. In this way, all user requests for the first time are hit by the application's cache.

API applications do not maintain caching; API applications cannot share caching between their processes, so cache hit rates are too low to bear the cost of caching technology. The API application opens and closes the database connection on each request, and keeping the database connection open between requests causes an unrealistic amount of database connections to be turned on at the same time, and the utilization of each connection is very low. 5.3 Test Conditions

The test load was generated by 10 HTTP client processes. Each process represents a separate set of users. A process generates a request for a user, then a request from a different user, and so on, until the first user produces another request.

For simplicity, 10 client processes run on the same machine as the Web server. This avoids the possibility that the network bottleneck will blur the test results. As stated in the application profile, the database system is also running on the machine.

Response time is not a problem under this test condition. We only measure throughput.

The API Web server in these tests is Netscape 1.1. 5.4 Test results and discussions

This is the test result:

    FastCGI  12.0 ms/Request = 83 Request/sec
    API      36.6 ms/request = 27 Request/sec

If fastcgi applications enjoy significant architectural advantages over API applications, it is no surprise that fastcgi applications run much faster. To understand these structures in greater depth, we measure two scenarios: an API with persistent connections. If you can avoid additional licensing fees, your API application will run much faster.

    API      16.0 ms/Request = 61 Request/sec

The answer is: it still can't be as fast as the fastcgi application. Deactivate the cached fastcgi. How much the fastcgi application benefits from its cache.

    FastCGI  20.1 ms/request = 50 Request/sec

The answer is: extremely large amounts of help, even though database access is fairly straightforward.

These two additional experiments show that if APIs and FASTCGI applications are implemented in exactly the same way-caching database connections without caching user profile data--api applications are slightly faster. This is expected because the FASTCGI application must bear the cost of interprocess communication, which does not exist in API applications.

These two applications are not actually implemented in the same way. FastCGI's architectural advantages lead to higher performance-3 times times in this test. This factor is higher when you use a remote database or a more expensive database access. This factor becomes smaller by using content files that require more processing. 6. Multithreading API

Now, Web servers with multithreaded internal structures (and accompanying APIs) are starting to become more common. These servers do not have all the disadvantages described in chapter 3rd. Does this mean that fastcgi's performance advantages will disappear.

A rough analysis agrees (with this view). API-based applications in a single process, multithreaded server can maintain caching and database connectivity in a FASTCGI application. API based applications are not burdened with the cost of interprocess communication, so API based applications will be slightly faster than fastcgi applications.

A deeper analysis denies (this view). Multithreaded programming is complex because concurrency makes it more difficult to test and debug programs. In the case of multithreaded programming of Web server APIs, the general problems of multithreading are mixed because of the lack of independence between applications and applications and Web servers. With FastCGI, you can write programs in a single thread style, get all the reliability and maintainability of process isolation, and still get very high performance. If you really need multithreading technology, you can write multithreaded fastcgi and still isolate your multithreaded applications from other applications and servers. In short, by excluding relative CGI's choice of fastcgi, multithreaded technology makes the Web server API unsuitable for almost all applications. In that argument the performance winner is obviously fastcgi. 7. Summary

How fast fastcgi is. The answer is: really very fast. Not because it has some specifically accelerated (specially-greased) paths through the operating system, but because its design adapts well to the needs of most applications. We invite you to use fastcgi as a fast, open foundation for your Web server application.