{"id":35106,"date":"2019-10-31T22:02:22","date_gmt":"2019-10-31T19:02:22","guid":{"rendered":"https:\/\/prohoster.info\/blog\/proizvoditelnost-setevyh-prilozhenij-linux-vvedenie\/"},"modified":"2019-10-31T22:02:22","modified_gmt":"2019-10-31T19:02:22","slug":"proizvoditelnost-setevyh-prilozhenij-linux-vvedenie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/proizvoditelnost-setevyh-prilozhenij-linux-vvedenie","title":{"rendered":"Performance of Linux network applications. Introduction.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Web applications are now used everywhere, and among all transport protocols, HTTP takes the lion's share. When studying the nuances of web application development, most people pay very little attention to the operating system where these applications actually run. The division between development (Dev) and operations (Ops) has only worsened the situation. However, with the spread of DevOps culture, developers are starting to take responsibility for running their applications in the cloud, making it very useful for them to get acquainted with the backend of the operating system. This is particularly beneficial if you're trying to deploy a system for thousands or tens of thousands of simultaneous connections.<\/p>\n

Limitations in web services are very similar to those in other applications. Whether it's load balancers or database servers, all of these applications have similar problems in a high-performance environment. Understanding these fundamental limitations and ways to overcome them will ultimately help evaluate the performance and scalability of your web applications.<\/p>\n

I am writing this series of articles in response to questions from young developers who want to become well-informed system architects. It is impossible to clearly understand Linux application optimization methods without diving into the basics of how they work at the operating system level. While there are many types of applications, in this cycle, I want to explore network applications, rather than desktop ones like browsers or text editors. This material is aimed at developers and architects who want to understand how Linux or Unix programs work and how to structure them for high performance.
\n<\/a><\/noindex>
\nLinux is a server<\/i> operating system, and most often your applications run on this OS. Although I say 'Linux', most of the time you can confidently assume that all Unix-like operating systems are meant in general. Nevertheless, I have not tested the accompanying code on other systems. So, if you're interested in FreeBSD or OpenBSD, the results may differ. When I try something specific to Linux, I indicate that.<\/p>\n

While you can use the knowledge gained to create an application from scratch and it will be well optimized, it's usually best not to do so. If you write a new web server in C or C++ for your organization's business application, it might be your last day at work. However, understanding the structure of these applications will assist you in selecting existing programs. You will be able to compare process-based systems with thread-based and event-based systems. You will understand and appreciate why Nginx outperforms Apache httpd, and why a Python application based on Tornado can handle more users compared to a Python application based on Django.<\/p>\n

ZeroHTTPd: A Learning Tool<\/h1>\n

\nZeroHTTPd<\/a><\/noindex>\u00a0\u2014 is a web server that I wrote from scratch in C as a teaching tool. It has no external dependencies, including access to Redis. We run our own Redis procedures. See below for more details.<\/p>\n

While we could discuss theory for a long time, there is nothing better than writing code, running it, and comparing all server architectures with each other. This is the most visually effective method. Therefore, we will write a simple web server ZeroHTTPd, applying each model: process-based, thread-based, and event-based. We will test each of these servers and see how they perform in comparison to one another. ZeroHTTPd is implemented in a single C file. The event-based server includes uthash<\/a><\/noindex>, a great implementation of a hash table that comes in a single header file. Otherwise, there are no dependencies to complicate the project.<\/p>\n

The code has many comments to help with understanding. As a simple web server in a few lines of code, ZeroHTTPd also serves as a minimal framework for web development. It has limited functionality but can serve static files and very simple \"dynamic\" pages. I must say that ZeroHTTPd is well suited for learning how to create high-performance Linux applications. Essentially, most web services wait for requests, check them, and process them. This is exactly what ZeroHTTPd will do. It is a teaching tool, not for production. It is not strong in error handling and is unlikely to boast best security practices (oh yes, I used strcpy<\/code>) or with an abstract C language trick. But I hope it will perform its task well.<\/p>\n

\"Performance
\nZeroHTTPd Homepage. It can serve different types of files, including images.<\/i><\/p>\n

Guest Book Application<\/h1>\n

\nModern web applications are typically not limited to static files. They involve complex interactions with various databases, caches, etc. Therefore, we will create a simple web application called 'Guest Book,' where visitors can leave entries under their names. The guest book retains previously left entries. There is also a visitor counter at the bottom of the page.<\/p>\n

\"Performance
\nZeroHTTPd Guest Book Web Application<\/i><\/p>\n

The visitor counter and guest book entries are stored in Redis. Custom procedures for communicating with Redis have been implemented and are independent of external libraries. I am not a big fan of rolling out homemade code when there are public and well-tested solutions available. However, the goal of ZeroHTTPd is to explore Linux performance and access to external services, while handling HTTP requests seriously impacts performance. We need to maintain full control over communications with Redis in each of our server architectures. In one architecture, we use blocking calls, while in others, we use event-driven procedures. Using an external Redis client library would not provide such control. Moreover, our small Redis client only performs a few functions (get, set, and increment a key; get and add to an array). Additionally, the Redis protocol is remarkably elegant and simple. You don't even need to learn it explicitly. The fact that the entire protocol work is managed in about a hundred lines of code speaks volumes about its thoughtful design.<\/p>\n

The next figure illustrates the actions of the application when a client (browser) makes a request. \/guestbookURL<\/code>.<\/p>\n

\"Performance
\nHow the guest book application works<\/i><\/p>\n

When a guestbook page needs to be generated, a single call is made to the file system to read the template into memory, along with three network calls to Redis. The template file contains most of the HTML content for the page shown in the screenshot above. It also includes special placeholders for the dynamic content part: entries and the visitor counter. We retrieve these from Redis, insert them into the page, and deliver the fully formed content to the client. The third Redis call could be avoided, as Redis returns the new value of the key when incremented. However, for our event-driven asynchronous architecture server, multiple network calls serve as a good test for educational purposes. Thus, we discard the returned Redis value for the visitor count and request it with a separate call.<\/p>\n

ZeroHTTPd Server Architectures<\/h1>\n

\nWe build seven versions of ZeroHTTPd with identical functionality but different architectures:<\/p>\n