Web application, the essence is a variety of Web content from the Web site to reach the browser, presented to the user. The less time a user wants to get web content, the better. From the perspective of Web sites, there are two major metrics: throughput and concurrency, which need to be addressed when a large number of users are concurrently accessing the latency problem. Throughput refers to the number of requests (REQ/S) that are completed per unit time. Concurrency refers to the number of simultaneous client requests (the browser sends a request with a certain degree of concurrency, such as the ability to send 4 requests simultaneously, which counts 4 clients). In a certain degree of concurrency, the larger the throughput, the less the customer feels the delay, the higher the performance of the site.
The throughput of a website is not a constant under different degrees of concurrency. In general, when the degree of concurrency is less than a certain threshold, the site can maintain relatively stable throughput, while exceeding this threshold, the site's throughput is rapidly declining. This threshold is determined by the speed at which messages are processed on the site. Assuming that the network bandwidth is not a bottleneck, the request message reaches the site, is cached in the kernel's buffer queue, and is then processed in parallel. When a Web site processes messages faster than the message buffer, messages in the queue accumulate, resulting in a rapid increase in processing latency and a rapid decline in throughput. In a typical stress test model, it is common to simulate multiple users sending messages in parallel, and a user receives a response from the previous message before the next message is sent. Therefore, if the site message processing time extension, the message sending interval naturally extended, the unit time in the flow of the site to reduce the message, which will lead to a decline in site throughput, resulting in a new throughput to achieve message processing and message arrival balance. But in the real scene, during the peak of the visit, impatient users will constantly refresh the browser, rushing to the site's request message volume continues to exceed the actual processing capacity of the site, requests are piled up in the site's buffer, until the site's memory exhaustion, resulting in the site paralysis. Therefore, in the real scene in order to avoid site paralysis, to take traffic control measures.
To speed up Web sites and improve Web performance, you typically have the following actions:
Improved server IO concurrency model. There are three classic IO concurrency models: process concurrency, thread concurrency, and event concurrency. In these three models, event concurrency is the most lightweight because multiple events are handled in a single thread, greatly reducing thread switching time and saving memory. So the nginx/lighttpd with the event concurrency model can withstand the most concurrency.
Caches site content. There are two situations: 1) Caching static results of dynamic content, accelerating dynamic content, and 2) caching site content closer to the customer, saving bandwidth.
Accelerate dynamic content computing. For CPU-intensive dynamic scripting, cache opcode, and do not parse the original script every time. The server script parser runs a cache of opcode, which is much more efficient than parsing the original script directly. This is why the Php/python parsing engine needs to compile the original script into opcode and then resolve the execution by the virtual machine so that it can achieve the same performance as Java and C #. Multiple conversions, the root cause is to improve performance.
Accelerates database access. There are several ways: 1) Increase the distributed cache, cache query results, 2) build the index, 3) increase the internal DBMS query cache, 4) internal DBMS cache index and data. The latter two are available through the database configuration.
Increase network bandwidth. If network bandwidth becomes a bottleneck, increase network bandwidth appropriately.
The logical schema is as shown.
650) this.width=650; "Src=" http://img.blog.csdn.net/20141107180712467?watermark/2/text/ ahr0cdovl2jsb2cuy3nkbi5uzxqvbwfzb256b3u=/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/dissolve/70/gravity/ Southeast "/>
Different web content, because of different characteristics, performance bottlenecks are often different, the required web acceleration strategy is not the same.
static content (small file). For example, a variety of picture content, the required bandwidth is relatively small. The site handles bottlenecks in IO concurrency. Therefore, you can choose a lightweight Web server that supports the event concurrency model, such as NGINX/LIGHTTPD. At the same time, in order to avoid frequent TCP establishment and connection, the KeepAlive long connection function of HTTP protocol can be opened. There is a large number of idle connections, and the epoll concurrency model needs to be turned on. At the same time, the last-modified / if-modified-since,etag / if-none-match,expires of the HTTP protocol can be used to update infrequent content. / cache-control such as header domain negotiation, in the browser cache content.
-
static content (large file). For example, a variety of download resources, the required bandwidth is large. At this point the bottleneck is often in bandwidth, the cache server can be deployed near the customer's location, and the caching policy of the cache server adheres to the HTTP header domain negotiation.
-
static content (VIDEO). The video content is often very large, but the user does not pursue the highest download speed, as long as it can catch the playback speed on the line. But the video lasts a long time, from a statistical point of view the required bandwidth is very large, and now high-definition video, single-channel video bandwidth requirements are also very large. So the closest deployed cache server is often the choice.
-
dynamic content. Bottlenecks in dynamic computing and databases, generally implement the following strategies: 1) Cache opcode;2) accelerates database access, 3) caches content that is not frequently updated, and uses cache servers or Web browsers to cache static contents. Dynamic content tends to show amazing concurrency performance gains after static.
Taking into account the content characteristics of the site, flexible application of the above acceleration strategy, you can reduce server/bandwidth costs, to achieve the highest cost-effective.
This article is from "Hasty Making blog" blog, please be sure to keep this source http://cangfu.blog.51cto.com/5966711/1574445
Talk about web acceleration