Notes on building a high-performance web site-application notes on building a high-performance web site-Infrastructure

• Notes on building a high-performance web site-Infrastructure
• Building a high-performance web site-ApplicationProgramArticle

Cause

It took me less than a month to finish reading this 400-page book "Building a high-performance web site". I have to say that this is the first time I have fully read a book in the real sense, although I have read many technical books. One of the reasons is that most of the technical books tend to be boring. Even if you read them with some devout purpose and desire, it is easy to give up halfway. However, this book is different. It attracts my desire to read it, and almost all links can resonate with me, so I quickly read it again.

The author uses typical lamp as an example. I have almost never touched on this aspect, but I believe that the idea is consistent, and the foundation of thinking is the key. Therefore, this article is a summary of the Summary.

 

Concept

Throughput: A web service performance indicator that represents the number of requests processed per second. This indicator is affected by three factors: number of concurrent users, total number of requests, and type of requested resources. Sometimes, when the total number of requests is certain, the more concurrent users, the higher the throughput. In addition, a file of several KB is requested and a file of several Mb is requested, the final processing time is obviously different. Therefore, throughput is a comprehensive indicator, not the concurrency capability.

 

Overview

It briefly describes the typical relationship between the user's browser, proxy server, web server and Application Server. Of course, the application server is usually included in the web server at the same time, which is drawn separately to differentiate duties.

 

Cache

When building a high-performance web site, we should leave the infrastructure aside (the database partition problem is also included in the infrastructure). At the application and coding level, we should mainly consider the cache design, reasonable cache design can greatly improve the performance of websites that provide dynamic Web Services. Of course, designing a cache solution in the architecture stage is not a simple technical problem. We need to start from the business and then combine various technologies. The following describes the cache design for each link in the order of an HTTP request from a technical perspective.

 

Client Cache

The cache mechanism of the client browser can be used to reduce the number of browser requests to the server (of course, the image and other resources on the server can be merged, and HTTP requests can also be reduced by combining CSS Image Positioning Technology ), using HTTP cache negotiation, you can design a flexible Client Cache solution. The content in the HTTP header is related to cache negotiation:

Last-modified: When a dynamic page actively pushes this value, it indicates that the browser preferentially uses the IF-modified-since value to negotiate with the server during the next request to the same URL, if the cache does not expire, the server does not need to re-calculate the dynamic web page, and returns the 304 notification to the browser. This method is often used for static website resources. However, this method has one drawback: Sometimes, although the last modification time of the file has been changed, the content has not changed, so the browser cache cannot be fully utilized.

Etag: the Web server generates a hash value for each URL and adds it to the etag tag of the HTTP header, the browser will first use if-None-match with this hash value to negotiate cache expiration. By performing MD5 transformation on the content of the static file, you can generate a hash value to make up for the shortcomings of last-modified. However, it brings about the computing overhead of the MD5 transformation on the server.

Expires: although the above two methods can avoid repeated dynamic web page resolution and computing on the server side, the browser must negotiate through HTTP requests, it does not actually reduce the number of requests. By adding the expires mark in the HTTP header, You can explicitly inform the browser of the expiration form, and the browser will completely reduce the number of requests.

 

Reverse Proxy Cache

There is also a reverse proxy server cache at the front end of the Web server. The reverse proxy server is essentially a proxy server. It only forwards requests from the Internet to the web server in the Intranet for processing. They all work at the application layer and can understand the HTTP protocol. The forward proxy server has HTTP caching, HTTP filtering, and other functions. The reverse proxy server also has the HTTP caching capability, and also has a certain degree of security. All http-friendly dynamic programs can also implement caching on reverse proxy servers. Heavyweight squid, lightweight varnish, and even web server software such as nginx can be used as reverse proxy services.

The preceding proxy server software products can Cache HTTP-based Web responses through various configurations.

 

Web Server Cache

The Web server may support URL-based caching (based on key-value pairs), which is similar to reverse proxy caching. Cache can be stored in memory or disk by configuration. The cache validity period is usually determined based on the header information in the HTTP protocol. However, you must note the following when using this mechanism:

1. Dynamic programs may become dependent on specific Web servers.
2. Note that writing http-Cache-friendly dynamic programs will make your dynamic programs more active.

The Web server also has the ability to cache file descriptors (like handles), which can reduce open operations on files. It is also a measure to reduce system calls, which has some effect on some small files, because the more small files, the more overhead the open, the more important the proportion will be.

 

Application Cache

The application itself can cache dynamic content, which can be reflected in three layers:

• Dynamic script cache: it takes a certain amount of time to parse the script. to speed up this process, some server-side scripting languages support dynamic script pre-compilation, such as the familiar ASP. net and JSP all have so-called intermediate languages. parsing these intermediate languages will be much faster.
• Caching supported by the dynamic script framework: some dynamic Script frameworks support caching. You should also pay attention to the caching mechanisms and principles of these frameworks during the selection, such as how to store the cache and how to set the expiration time, whether local cache is supported.
• Applications implement caching themselves: applications independently design caching based on specific business needs.

The specific technical aspects of cache design are as follows:

• The cache is in the memory. The advantage of this method is that it reduces disk read/write, but the memory is limited and it is not easy to expand on a single machine.
• Cached in the distributed cache. This method reduces disk read/write and improves reliability and scalability. However, due to network I/O requirements, the performance is slightly inferior to the single-host cache.
• Partial page cache. If some pages cannot be fully cached, consider local cache.
• Static: static websites can greatly improve the performance, because users' requests do not need to be processed by dynamic scripts.

 

Constraints on server system capabilities

This part of content is universally applicable to all servers (proxy servers, Web servers, and others.

• Multi-process and multi-thread selection and scheduling: process switching and thread switching both require a certain amount of system overhead. Generally, web server software that uses a multi-thread model has better performance than multi-process.
• System Call: some function calls that need to switch from user mode to kernel mode are called system calls, for example, opening a file. System calls have a certain amount of overhead. Reducing system calls is a program design detail that can speed up processing.
• TCP link Persistence: You can maintain TCP links to reduce the creation and closure of TCP links between the server and the client. The connection: keep-alive in HTTP has this function.
• Io model: Because the CPU speed is much faster than Io, Io latency is often a performance bottleneck, so the IO model is very important.

Various Io models:

Pio: the CPU directly interferes with the Data Interaction Between the disk and the memory, that is, data from the memory to the disk or from the disk to the memory must go through the CPU register. Such a model can be imagined that the CPU has a lot of time to wait for a slow device.

Direct Memory Access: the CPU sends commands to the DMA controller to control data processing. After data is processed, the CPU is notified, which can largely release CPU resources.

Synchronous blocking I/O: For processes, some system calls block processes to different degrees in order to synchronize Io, such as accept, send, and read.

Synchronous non-blocking I/O: For a process, some system calls can be returned immediately after the call, informing the process of Io readiness to avoid blocking the process.

Multi-channel I/O readiness notification: For synchronous non-blocking I/O methods, the process still needs to poll the file descriptor (handle) to know which Io is ready, multiple I/O-ready notifications change this process to callback notifications.

Memory ing: maps a file to an address space in the memory to write files in the same way as the memory. Of course, this method is essentially no different from writing files.

Direct I/O: there is usually a kernel buffer under the operating system's jurisdiction between the user's process address space and the disk. When writing files, this buffer is generally written, then, some latency policies are used to write data to the disk. This improves the write efficiency. However, for applications such as databases, you often want to manage the read/write cache on your own to avoid the fearless memory waste in the kernel buffer. Linux open functions support the o_direct parameter for direct Io.

Sendfile: if the web server wants to send a file, it will go through the following process: open the file and read the file content from the disk (this usually involves copying the kernel buffer data to the user process ), then the process sends the file content through the socket (this is usually designed to copy the user process data to the NIC kernel buffer), you can see that duplicate data replication can be avoided. Sendfile can be copied directly from the file kernel buffer to the NIC kernel buffer.

 

Summary

This article summarizes the key points of building a high-performance web site from the application layer, and mainly discusses the implementation technology of cache.

labor fruit, reprinted please indicate the source: http://www.cnblogs.com/P_Chou/archive/2012/10/13/high-performance-web-site-program.html