Mention the performance of Web applications liter has never been more urgent.
The proportion of online economic activities is increasing, and even more than 5% of economic activities in developing countries and regions have been conducted online (for relevant data, please refer to the resources at the back of this article). In this modern world with hyperlinks and online at any time, the expectations of users are far from what they used to be. If your website can't respond immediately, your application can't run immediately, and users will turn around and turn to your competitors.
A study by Amazon about 10 years ago showed that a 1/10 second reduction in page load time can increase its revenue by 1%. Another recent survey also showed that more than half of interviewed site owners mentioned that poor performance of their applications has led to reduced revenue or loss of users.
How fast is a website? For every second it takes for a page to load, about 4% of users leave. The first interaction time of the top ranked e-commerce site is 1 to 3 seconds, and the conversion rate in this interval is the highest. Obviously, the importance of web application performance is increasing day by day.
Improving performance is actually not difficult, but how to see the results is difficult. This article gives 10 suggestions that can improve website performance by about 10 times for your reference. This comprehensive coverage of various performance optimization techniques is the first time, but these suggestions may require a little support from NGINX. In addition to performance, these recommendations also involve improving security.
1 Recommendation 1: Use a reverse proxy server to make applications faster and more secure
As if your Web applications only run on a single machine, it should improve its performance is very simple: replace faster, and more with several processors, several pay more memory, disk arrays have high speed. After the change, the WordPress server, Node.js or Java application running on this machine will speed up. (If the application will access another database server, it is also simple: find two faster machines and connect them with a faster network)
The trouble is that machine speed is not an issue. In many cases, web applications are slow because they have to switch between various tasks. After a while, they have to handle thousands of user requests on connections, and then they have to read and write files to the disk, and then they have to run the application code, and then they have to do it again. Something else. As a result, the application server may have various conditions, running out of memory, swapping files, or making many requests waiting for tasks such as a hard disk I/O.
In addition to upgrading the hardware, you can actually choose another completely different method: add a reverse proxy server to share some of the above tasks. The reverse proxy server is located in front of the machine running the application and is responsible for processing requests from the external network. The reverse proxy server is directly connected to the Internet, and it communicates with the application server using a fast internal network.
The reverse proxy server allows the application server to focus on building the page, and then hand it over to the reverse proxy to send it to the Internet without having to care about the interaction between the user and the application. Because there is no need to wait for the client's response, the operating speed of the application server can reach a near-optimal level.
Adding a reverse proxy server can also add flexibility to the Web server. For example, if the server performing a certain task is overloaded, another server of the same type can be added at any time; and if this server goes down, it is easy to replace it.
In view of this flexibility, reverse proxy servers are often a prerequisite for other performance optimization methods, such as:
-
Load balancing (see "Recommendation 2"), the reverse proxy server runs a load balancing service, and the traffic is evenly distributed to several application servers. With load balancing, adding application servers does not require modifying applications at all.
-
Cache static files (see "Recommendation 3"), files that can be directly requested, such as pictures or codes, can be stored in the reverse proxy server for direct delivery to the client. This will not only respond to requests faster, but also reduce the burden on the application server and speed up its operation.
-
To ensure site security, you can configure a reverse proxy server to improve its security level, and use it to monitor to quickly identify and respond to attacks, thereby preserving the security of the application server.
NGINX is specifically designed for the use of reverse proxy servers, which naturally supports the above optimizations. Due to the event-driven processing mechanism, NGINX is more efficient than traditional servers. NGINX Plus adds more high-end reverse proxy functions, such as application medical examination, unique request routing, advanced caching, and after-sales support.
Comparison of traditional server and NGINX Worker
Recommendation 2: Increase load balancing server
By adding load balancing server is relatively simple, but it can significantly improve site performance and security. By distributing the traffic to multiple servers, it is not necessary to upgrade the Web server. Even if the application itself is not well written or is difficult to scale, load balancing can improve the user experience without making other changes.
The load balancing server is first a reverse proxy server (see "Recommendation 1"), which is responsible for forwarding requests from the Internet to other servers. The key here is that the load balancing server can support more than two application servers, using a selection algorithm to distribute requests among different servers. The simplest load balancing algorithm is round-robin scheduling, which forwards new requests to the next server among the available servers in turn. Other algorithms include sending requests to the server with the fewest active connections. NGINX Plus supports a function that keeps user sessions on the same server, which is called session persistence.
Load balancing servers can prevent one server from being overloaded while other servers are too idle, thereby greatly improving performance. At the same time, it can also make web server expansion easier, because you can choose a cheaper server, while ensuring the best use of the material.
Protocols that can be scheduled through load balancing include HTTP, HTTPS, SPDY, HTTP/2, WebSocket, FastCGI, SCGI, uwsgi, memcached, and other application forms, including TCP-based applications and other fourth-layer protocols. To this end, we must first analyze the Web application to see where the performance shortcomings are, and then determine which one to use.
The same server or a server used for load balancing can also undertake other tasks, such as SSL termination, support for HTTP/1/x or HTTP/2 depending on the client, and caching static files.
NGINX is often used for load balancing. For more information, please refer to our previous introductory articles, articles about configuration, e-books and related online videos, and of course documents. Our commercial version, NGINX Plus, supports more load balancing functions, such as load balancing based on server response time and load balancing that supports the Microsoft NTLM protocol.
Recommendation 3: Cache static and dynamic content
Cache memory can improve Web application performance, because they can more quickly deliver the content to the client. Caching strategies include preprocessing content, storing content on faster devices, storing content close to the client, and applying these strategies at the same time.
There are two types of cache.
-
Static content cache, infrequently changing files, such as pictures (JPEG, PNG) and code (CSS, JavaScript), can be stored in the edge server for quick retrieval from the content or disk.
-
Dynamic content caching, many web applications will generate brand new HTML for each page request, and cache each generated HTML for a short period of time, which may significantly reduce the total number of pages that need to be generated, while ensuring that the delivered content is fresh enough.
Suppose a page is viewed 10 times per second, and you cache it for 1 second, then 90% of the requests for this page will come from the cache. If you cache static content separately, even the newly generated pages will most likely come from the cached content.
There are three main technologies for caching content generated by web applications.
-
Put the content close to the user. Close to the user, less transmission time.
-
Put the content on a faster machine. The machine is fast and the retrieval speed is fast.
-
Take content away from overused machines. Sometimes machines are much slower than when they are focused on performing specific tasks. That's because too many tasks distract them. At this time, taking the content to other machines is not only good for the cached content, but also for the non-cached content, because the burden on the host hosting them is reduced.
Web application caching can be implemented inside or outside the Web application server. First, consider caching dynamic content to reduce the load on the application server. Second, caching is used for static content (including temporary copies of dynamically generated content) to further reduce the burden on the application server. Then, consider moving the cache to other machines that are faster or closer to the user to reduce the burden on the application server and shorten the transmission time.
Good use of cache can significantly speed up the response speed of the application. For many web pages, static data such as big pictures often occupies more than half of the content. Without caching, querying and transmitting such data may take several seconds, while with caching, it may take only a fraction of a second.
An example can be given to illustrate how to use the cache. NGINX and NGINX Plus use two commands to set the cache: proxy_cache_path and proxy_cache specify the location and size of the cache, the maximum cache time, and other parameters. Using the third (and very popular) command proxy_cache_use_stale, you can even tell the cache to provide the original old files when the server that should provide fresh content is too busy or down. For the client, it’s better to get the content. Can't get strong. From the user's point of view, this can also establish a very stable image of your site or application.
NGINX Plus supports advanced caching functions, including caching purging and displaying the cache status in a visual form through the control panel to achieve real-time monitoring.
To learn more about caching in NGINX, you can look at the reference documentation and NGINX Content Caching in the NGINX Plus Admin Guide.
Note: Caching involves development, decision-making, and operation and maintenance. A complete caching strategy, such as those mentioned in this article, can reflect the value from the perspective of DevOps. In other words, developers, architects, and operation and maintenance personnel join hands at this time to jointly ensure the functionality, response time, security, and business goals of a website.
Recommendation 4: Compress data
Pressure reduction can greatly improve the performance of the same. Pictures, videos, music and other files have very mature and efficient compression standards (JPEG and PNG, MPEG-4, MP3), any standard can reduce the file size by an order of magnitude or more.
Text files, including HTML (plain text and HTML tags), CSS and JavaScript code, are often transferred without compression. Compressing these data is sometimes particularly obvious in improving the perceived performance of Web applications, especially when the mobile user's network is slow and unstable.
Because text data can play a necessary support role for page interaction, while multimedia data is more of an icing on the cake. Smart content compression can reduce text content such as HTML, JavaScript, CSS, etc. by more than 30%, so it can reduce loading time accordingly.
If you use SSL, compression can reduce the amount of data that must be SSL-encoded, thereby compensating for the CPU time to compress the data.
There are many ways to compress data. For example, the HTTP/2 part of Recommendation Six describes a novel compression idea, which is particularly suitable for header data compression. There is also an example of text compression, that is, GZIP compression can be turned on in NGINX. After pre-compressing the text data, you can use the gzip_static command to send the .gz file directly.
Recommendation Five: Optimize SSL/TLS
The more growing number of sites using Secure Sockets Layer (SSL) and later the Transport Layer Security (TLS) protocol. SSL/TLS enhances website security by encrypting the data sent from the origin server to the user. Google will improve the search engine rankings of websites that use SSL/TLS, which will strongly promote this process.
Despite the increasing adoption rate, the performance loss caused by SSL/TLS has plagued many websites. There are two reasons why SSL/TLS slows down websites.
1. An encryption key must be created for the initial handshake every time a new connection is opened, and the browser uses HTTP/1.x to establish multiple connections for each 2. The way the server establishes multiple connections further exacerbates this problem.
The operations of encrypting data on the server side and decrypting data on the client side are also overhead.
In order to encourage people to use SSL/TLS, the authors of HTTP/2 and SPDY (see Recommendation 6) designed these two protocols to allow the browser to establish only one connection for a session. This eliminates one of the two main causes of performance degradation caused by SSL. However, when it comes to optimizing SSL/TLS performance, there is still a lot to do.
The method of optimizing SSL/TLS varies from web server to web server. Take NGINX as an example. NGINX uses OpenSSL and runs on an ordinary machine, which can provide performance close to that of a custom machine. NGINX SSL performance details how to minimize the overhead of SSL/TLS encryption and decryption.
In addition, there is an article here that introduces many ways to improve SSL/TLS performance. To summarize briefly, the technologies involved are mainly as follows.
-
Session cache. Use the ssl_session_cache command to enable the cache, and cache the parameters used every time an SSL/STL connection is made.
-
Session ticket or ID. Save the information of a specific SSL/TLS session as a session ticket or ID so that the connection can be reused without having to re-handshake.
-
OCSP envelope. Reduce handshake time by caching SSL/TLS certificate information.
Both NGINX and NGINX Plus can terminate SSL/TLS, that is, handle the encryption and decryption of client information while maintaining clear text communication with other servers. These steps can be taken in NGINX or NGINX Plus to handle SSL/TLS termination. For using NGINX Plus on a server that accepts TCP connections, you can refer to the setup steps here.
Recommendation 6: Implement HTTP/2 or SPDY
It has been the site using SSL / TLS, and if we use the HTTP / 2 or SPDY is likely to enhance the performance, because as long as a connection handshake. For sites that have not yet used SSL/TLS, HTTP/2, and SPDY, switching to SSL/TLS (which usually reduces performance) may be a step backwards in terms of response speed.
Google started the SPDY project in 2012 and is committed to achieving faster speeds on top of HTTP/1.x. HTTP/2 is the SPDY-based standard recently approved by the IETF. SPDY is widely supported, but will soon be replaced by HTTP/2.
The key to SPDY and HTTP/2 is to use only one connection instead of multiple connections. This one connection is multiplexed, so it can carry multiple requests and responses at the same time.
Only one connection is maintained, which saves the setup and management consumption required for multiple connections. And a connection is particularly important for SSL, because it can minimize the handshake time required for SSL/TLS to establish a secure connection.
The SPDY protocol requires the use of SSL/TLS, and HTTP/2 has no formal requirements, but all browsers that currently support HTTP/2 will only use it when SSL/TLS is enabled. In other words, browsers that support HTTP/2 will only use HTTP/2 if the website uses SSL and the server accepts HTTP/2 traffic. Otherwise, the browser will communicate based on HTTP/1.x.
After SPDY or HTTP/2 is implemented, the previous performance optimization measures for HTTP such as domain name segmentation, resource merging, and image sprites are no longer needed. Therefore, code and deployment can be simplified. Regarding the changes that HTTP/2 will bring, you can refer to our white paper.
NGINX has been supporting SPDY very early, and most sites that use SPDY today are running NGIN
X. NGINX is also the first to support HTTP/2. In September 2015, NGINX open source and NGINX Plus began to support HTTP/2.
Over time, NGINX hopes that most sites will enable SSL and migrate to HTTP/2. This will not only make the site more secure, but as new optimization techniques continue to emerge, higher performance can also be achieved through simple code.
Recommendation 7: Upgrade the software
Provide a simple method for application performance liter, is selected based on the reliability and performance of the software. In addition, developers of high-quality components are more likely to continuously improve performance and fix problems, so it is cost-effective to use the latest stable version. The newly released version will get more attention from developers and users, and will also take advantage of new compiler optimization techniques, including tuning for new hardware.
Compared with the old version, the newly released stable version has significantly higher performance. Persist in upgrading, you can also ensure that you keep up with the times in tuning, problem repair, and security alerts.
Failure to upgrade the software will also hinder the use of new capabilities. For example, HTTP/2 currently requires OpenSSL 1.0.1. Starting from the second half of 2016, HTTP/2 will require OpenSSL 1.0.2, which was released in January 2015.
NGINX users can start with the latest version of NGINX open source software or NGINX Plus, which supports socket sharing, thread pooling (see below), and will continue to optimize performance. Therefore, check your own software and try to upgrade them to the latest version.
Recommendation 8: Tuning Linux
L inux is the underlying operating system today, most Web servers as the foundation of all infrastructure, Linux to enhance performance is critical. By default, many Linux systems are relatively conservative, only relying on desktop office as the requirement, and taking up a small amount of resources as the tuning goal. For web applications, in order to achieve the best performance, it must be re-tuned.
Linux optimization varies from web server to web server. Taking NGINX as an example, you can consider the following aspects.
Inventory queue. If you find that some connections cannot be processed, you can increase net.core.somaxconn, which is the maximum number of connections waiting for NGINX to process. If this connection limit is too small, you should see an error message. You can gradually increase this value until the error message no longer appears.
-
File descriptor. NGINX uses up to two file descriptors for each connection. If the system serves many connections, you may need to increase the sys.fs.file_max system-level limit on descriptors and the nofile limit on user file descriptors to support the increased load.
-
Temporary port. When used as a proxy, NGINX will create temporary ports for each upstream server. You can set net.ipv4.ip_local_port_range to increase the range of port values to increase the number of available ports. In addition, you can also reduce the value of net.ipv4.tcp_fin_timeout, which controls the waiting time for the release and reuse of inactive ports and speeds up the turnover.
-
For NGINX, please refer to the NGINX Performance Tuning Guide to learn how to effortlessly optimize your Linux system to support greater throughput.
Recommendation Nine: Tuning the Web Server
No On what Web server, you need to apply for their tune. The following suggestions apply to any web server, but will give instructions for setting up only NGINX.
-
Access log. Don't write every requested log to disk immediately, you can cache it in memory and then batch it in. For NGINX, the buffer=_size_ parameter is added to the access_log instruction, and the log is written to disk after the memory buffer is full. If you add the **flush=_time_** parameter, the contents of the buffer will also be written to the disk at the specified time.
-
buffer. The buffer is used to store part of the response in the memory until the buffer is filled, which can achieve a more effective response to the client. Responses that cannot be written to memory will be written to disk, reducing performance. When NGINX buffering is enabled, proxy_buffer_size and proxy_buffers instructions can be used to manage it.
-
Client active connection. Active connections can reduce time consumption, especially when using SSL/TLS. For NGINX, the value of keepalive_requests can be increased for the client, and the default value is 100; the value of keepalive_timeout can also be increased to make the active connection last longer, so that subsequent requests can be responded to faster.
-
Upstream activity connection. Upstream connections, that is, connections to application servers and database servers, can also benefit from the active connection settings. For upstream connections, you can increase the number of active connections, that is, the number of idle active connections available for each worker process. This can improve connection reuse and reduce reopening of connections. For more information about active connections, please refer to this blog.
-
limit. Limiting the resources used by the client can improve performance and security. For NGINX, the limit_conn and limit_conn_zone instructions limit the number of connections to the specified source, while limit_rate limits the bandwidth. These settings can prevent legitimate users from "sweeping" resources and also help prevent attacks. The limit_req and limit_req_zone instructions limit client requests. For the connection to the upstream server, you can use the max_conns parameter in the server command in the upstream configuration area, which limits the connection to the upstream server and prevents overload. The related queue instruction will create a queue and save the specified number of requests for the specified time after the max_conns limit is reached.
-
Work process. The worker process is responsible for processing the request. NGINX uses an event-based model and OS-related mechanisms to effectively distribute requests among worker processes. It is recommended to set the value of worker_processes to one worker process per CPU. If needed, most systems support increasing the value of worker_connections (default is 512). You can find the value that best suits your system through experimentation.
-
Socket fragmentation. Usually, a socket listener distributes new connections to all worker processes. Socket fragmentation creates a socket listener for each worker process, and the kernel assigns a connection to the socket listener when it is available. This can reduce lock contention and improve performance on multi-core systems. To enable socket fragmentation, include the reuseport parameter in the listen command.
-
Thread Pool. A time-consuming operation will block any computer process. For web server software, disk access may hinder many faster operations, such as in-memory calculations and replication. In the case of a thread pool, slow operations will be assigned to a set of independent tasks, and the main processing loop will continue to run faster operations. After the disk operation is completed, the result is returned to the main processing loop. In NGINX, the read() system call and sendfile() are reposted to the thread pool.
Prompt to modify the settings of any operating system and peripheral devices, modify only one item at a time, and then test the performance. If the change causes a problem, or does not improve performance, change it back.
Recommendation 10: Monitor real-time dynamics to find problems and bottlenecks
Paul critical applications store high-performance real-time monitoring of application performance. The dynamics of specific devices and applications in the corresponding Web infrastructure must be monitored in real time.
Monitoring site activity is mostly passive. It only tells you what happened. As for how to find and solve problems, it's your own business.
Monitoring can catch the following types of problems:
1. The server is down
2. The server is unstable and the connection is missed
3. The server has a large area of cache failure
4. The content sent by the server is incorrect
Global performance monitoring tools such as New Relic or Dynatrace can help us monitor the time of remote page loading, while NGINX can help you monitor the application delivery side. The performance data of the application can tell you when the optimization method really brings a different experience to the user, and when the capacity needs to be expanded to meet more and more traffic.
In order to help users find problems as soon as possible, NGINX Plus has added an application physical examination function, which will report frequently recurring problems. NGINX Plus also has a session draining feature, which prevents new connections before the existing tasks are completed, and slow-start capacity, so that the restored server can reach the desired speed in the load balancing cluster. When used properly, the health check will help you locate the problem before it significantly affects the user experience, while session draining and slow start allow you to replace the server without affecting the perceived performance and online time. This picture shows the built-in real-time activity monitoring control panel of NGINX Plus, covering the server, TCP connection and cache.
Conclusion: 10 times performance improvement
Sex can improve there will be a huge difference because of different Web applications. The actual improvement depends on budget, time, and the gap between the current implementation and the ideal performance. So how do you get 10 times the performance improvement of your application?
In order to help you understand the potential of each optimization suggestion, the following will give some implementation guidelines for the previous suggestions. I hope you will get what you need.
-
Reverse proxy server and load balancing. No load balancing or pool load balancing can result in extremely low performance. Adding a reverse proxy server, such as NGINX, can reduce the round-trip between memory and disk for web applications. Load balancing can transfer tasks from overloaded servers to idle servers, and it is also convenient for expansion. These changes can greatly improve performance. Compared with the worst case of the original deployment method, the performance improvement of 10 times is very easy, even if it is less than 10 times, there is a qualitative leap in overall.
-
Cache dynamic and static content. If your web server also acts as an application server, you can achieve a 10-fold performance improvement during peak periods by caching dynamic content. Caching static content can also improve performance several times.
-
Compress the data. Using compression formats such as JPEG, PNG, MPEG-4, and MP3 can significantly improve performance. If these methods are used, the compressed text data (code and HTML) can double the initial page load time.
-
Optimize SSL/TLS. The secure handshake has a great impact on performance, so optimizing it can make the initial response twice as fast, especially for websites with more text content. The performance improvement brought by optimizing the media files under SSL/TLS is very small.
-
Implement HTTP/2 and SPDY. In the case of using SSL/TLS, these two protocols may improve the overall performance of the website.
-
Tuning Linux and Web server. Using optimized buffering strategies, using active connections, and reloading time-consuming tasks to an independent thread pool can significantly improve performance. For example, the thread pool can improve the performance of disk-intensive tasks by at least an order of magnitude.
I hope you will try the above techniques yourself, and I hope you all share your experience in performance improvement.
------------------------------------------- < END >---------------------------------------
Translator: write for it
Source: www.zcfy.cc/article/10-tips-for-10x-application-performance-nginx-22.html
Original: https://www.nginx.com/blog/10-tips-for-10x-application-performance/