Book Image

Nginx Troubleshooting

By : Alexey Kapranov
Book Image

Nginx Troubleshooting

By: Alexey Kapranov

Overview of this book

Nginx is clearly winning the race to be the dominant software to power modern websites. It is fast and open source, maintained with passion by a brilliant team. This book will help you maintain your Nginx instances in a healthy and predictable state. It will lead you through all the types of problems you might encounter as a web administrator, with a special focus on performance and migration from older software. You will learn how to write good configuration files and will get good insights into Nginx logs. It will provide you solutions to problems such as missing or broken functionality and also show you how to tackle performance issues with the Nginx server. A special chapter is devoted to the art of prevention, that is, monitoring and alerting services you may use to detect problems before they manifest themselves on a big scale. The books ends with a reference to error and warning messages Nginx could emit to help you during incident investigations.
Table of Contents (15 chapters)
Nginx Troubleshooting
About the Author
About the Reviewers
Rare Nginx Error Messages

The caching layer of Nginx

If there is one universally known and acclaimed algorithm to speed things up, it is caching. Pragmatically speaking, caching is a process of not doing the same work many times. Ideally, each distinct computational unit should be executed once. This, of course, never happens in the real world. Still, techniques to minimize repetitions by rearranging work or using saved results are very popular. They form a huge discipline named "dynamic programming."

In the context of a web server, caching usually means saving the generated response in a file so that the next time when the same request is received; it could be processed by reading this file and not computing the response again. Now please refer to the steps outlined in the first section of this chapter. For many of the real-world websites, the actual computing of the responses is not the bottleneck; transferring those responses to the slow clients is. That's why the most efficient caching happens right in the browser...