Running lots of processes consumes lots of memory. Each open connection exclusively reserves an httpd process, meaning that at busy times, Apache needs to create a large number of processes. Browsers hold these connections open (a practice called HTTP keepalive) for a period of time to reduce delay for future requests the user might make during the session. To decrease page‑rendering time, web browsers routinely open six or more TCP connections to a web server for each user session so that resources can download in parallel. (For more details about these changes, check out the list of resources for Internet statistics at the end of this post.)Īll of these changes presented a real challenge to Apache’s process‑per‑connection model, which did not scale well in the face of high traffic volume and heavy pages (more embedded resources requiring more HTTP requests). Over the past 20 years, there has been explosive growth in the volume of traffic and the number of users on the World Wide Web.Īt the same time, the weight of web pages (the size and number of components the web browser has to fetch to render a page) has grown steadily, and users have become less and less patient about waiting for web pages to load.
Source: Netcraft November 2005 Web Server Survey Challenged by the Growth of the World Wide Web Its adoption at websites grew steadily, peaking at over 70% market share at the end of 2005. Processing of all other connections would continue undisturbed.Īpache quickly became the dominant web server on the early World Wide Web. Developers could add code secure in the knowledge that if it blocked, ran slowly, leaked resources, or even crashed, only the worker process running the code would be affected. The isolation and protection afforded by the one‑connection‑per‑process model made it very easy to insert additional code (in the form of modules) at any point in Apache’s web‑serving logic. Each process handled one connection at a time, and if all of the processes were busy, Apache created more worker processes to be ready for a further spike in traffic. When a prefork Apache web server received an HTTP connection, one of the httpd worker processes grabbed and handled it. The biggest downside was the cost of forking a new httpd worker process for each new connection, and Apache developers quickly adopted a prefork model in which a pool of worker processes was created in advance, each ready and willing to accept one new HTTP connection. The process read the request on the connection, calculated the response and wrote it back down the connection, and then exited.Īpache took this model and ran with it. At that time, many network services were triggered from a master service called inetd when a new network (TCP) connection was received, inetd would fork( ) and exec( ) a Unix process of the correct type to handle the connection. The simplicity of Apache’s architectural model was key to its early success. There was a huge thirst in the early community to innovate with new technologies, and Apache was the platform of choice. Traffic levels were low, web pages were simple, bandwidth was constrained and expensive, and CPU was relatively cheap. It was created at a time when the World Wide Web was still a novelty. The Key to Apache’s Early SuccessĪpache was the backbone of the first generation of the World Wide Web, becoming the industry standard for web serving almost as soon as it debuted in 1995. My belief is absolutely not that Apache is unfit for purpose, but that in the face of modern web applications, it is now dated and needs support in order to function effectively. I write this as a very early user of Apache (and of NCSA’s httpd before that), as someone who wrote CGI scripts in bash and Perl before PHP was anywhere near mainstream, and as a one‑time software engineer at Zeus, one of the very first event‑driven web servers to challenge the Apache model of doing things. In this article, I’ll share my perspective on these changes and limitations, and explain how a modern web developer can respond. When Igor Sysoev began working on NGINX over 10 years ago, no one expected that the project he created for the purpose of accelerating a large Apache‑based service would grow to have the influence it has now.Īpache HTTP server is a solid platform for almost any web technology developed over the last 20 years, but time is showing that the architectural decisions made when the code was first laid down are becoming limiting factors in its suitability for modern web demands. The Apache HTTP server and NGINX are the two most popular open source web servers powering the Internet today.
0 kommentar(er)
