荔园在线

荔园之美,在春之萌芽,在夏之绽放,在秋之收获,在冬之沉淀

[回到开始] [上一篇][下一篇]


发信人: zzt (好好学习,天天向上), 信区: Linux
标  题: Apache 2.0 on the way....(转寄)
发信站: BBS 荔园晨风站 (Sat Sep 25 13:07:59 1999), 转信

【 以下文字转载自 zzt 的信箱 】
【 原文由 zhuzutao.bbs@bbs.net.tsinghua.edu.cn 所发表 】
发信人: Lamborghini (寻找欧宝中), 信区: Linux
标  题: Apache 2.0 on the way....(转寄)
发信站: BBS 水木清华站 (Sat Sep 25 10:31:49 1999)

                        Apache 2.0: The Next Generation

   It has been about a year since Apache 1.3 was released, and the core
   Apache members are now working on version 2.0. The new version will be
   significantly different to the current one, which raises issues such
   as "Why update Apache at all?" and "What does this update mean for
   Apache administrators?"

   We hope to answer those and many other questions in this article and,
   as the release of 2.0 approaches, provide more up to date information.

   It is important to note that presently there is only development code
   available for 2.0 and that downloading it now is not advised for
   anybody other than those who are already familiar with the Apache
   internals. The code in its current state is not guaranteed to compile
   from day to day or to work on many platforms.

   Apache Week will announce any upcoming alpha or beta versions and the
   details of the 2.0 release as soon as they are ready.

Why Go Beyond 1.3?

   Apache 1.3 is a great web server which serves pages for the vast
   majority of the web, but there are things it can't do. Firstly, it
   isn't particularly scalable on some platforms. AIX processes, for
   example, are very heavy-weight and a small AIX box serving 500
   concurrent connections can become so heavily loaded that it can be
   impossible to telnet to it. In situations like this, using processes
   is not the right solution: we need a threaded web server.

   Apache is renouned for being portable as it works on most POSIX
   platforms, all versions of Windows, and a couple of mainframes.
   However, like most good things, portability comes with a price which
   in this case is ease of maintenance. Apache is reaching the point
   where porting to additional platforms is becoming more difficult. In
   order to give Apache the flexibility it needs to survive in the
   future, this problem must be resolved by making Apache easy to port to
   new platforms. In addition, Apache will be able to use any specialised
   APIs, where they are available, to give better performance.

                       Multiple-Processing Modules (MPM)

   The original reason for creating Apache 2.0 was scalability, and the
   first solution was a hybrid web server; one that has both processes
   and threads. This solution provides the reliability that comes with
   not having everything in one process, combined with the scalability
   that threads provide. The problem with this is that there is no
   perfect way to map requests to either a thread or a process.

   On platforms such as like Linux, it is best to have multiple processes
   each with multiple threads serving the requests so that if a single
   thread dies, the rest of the server will continue to serve more
   requests. Other platforms such as Windows don't handle multiple
   processes well, so one process with multiple threads is required.
   Older platforms which do not have threads also had to be taken into
   account. For these platforms, it is necessary to continue with the 1.3
   method of pre-forking processes to handle requests.

   There are multiple ways to deal with the mapping issue, but the
   cleanest is to enhance the module features of Apache. Apache 2.0 sees
   the introduction of 'Multiple-Processing Modules' (MPMs) - modules
   which determine how requests are mapped to threads or processes. The
   majority of users will never write an MPM or even know they exist.
   Each server uses a single MPM, and the correct one for a given
   platform is determined at compile time.

What MPMs are available?

   There are currently five options available for MPMs. Their names will
   likely change before 2.0 ships, but their behaviours are basically
   set. All of the MPMs, except possibly the OS/2 MPM, retain the
   parent/child relationships from Apache 1.3. This means that the parent
   process will monitor the children and make sure that an adequate
   number are running.

   PREFORK
          This MPM mimics the old 1.3 behaviour by forking the desired
          number of servers at startup and then mapping each request to a
          process. When all of the processes are busy serving pages, more
          processes will be forked. This MPM should be used for older
          platforms, platforms without threads, or as the initial MPM for
          a new platform.

   PMT_PTHREAD
          This MPM is based on the PREFORK MPM and begins by forking the
          desired number of child processes, each of which starts the
          specified number of threads. When a request comes in, a thread
          will accept the request and serve the response. If most of the
          threads in the entire server are busy serving requests, a new
          child process will be forked. This MPM should be used on
          platforms that have threads, but which have a memory leak in
          their implementation. This may also be the proper MPM for
          platforms with user-land threads, although there has not been
          enough testing at this point to prove this hypothesis.

   DEXTER
          This MPM is the next step in the evolution of the hybrid
          concept. The server starts by forking a static number of
          processes which will not change during the life of the server.
          Each process will then create the specified number of threads.
          When a request comes in a thread will accept and answer the
          request. At the point where a child process decides that too
          many of its threads are serving requests, more threads will be
          created. This MPM should be used on most modern platforms
          capable of supporting threads. It should create the lightest
          load on the CPU while serving the most requests possible.

   WINNT
          This MPM is designed for use on Windows NT. Before Apache 2.0
          is released, it will also be made to work on Windows 95 and 98
          although, just like Apache 1.3, it is unlikely to be as stable
          as on NT. This MPM creates one child process, which then
          creates a specified number of threads. When a request comes in
          it is mapped to a thread that will serve the request.

   OS/2
          This MPM is designed for use on OS/2. It is purely threaded,
          and removes the concept of a parent process altogether. When a
          request comes in, a thread will serve it properly, unless all
          of the threads are busy, in which case more threads will be
          created.

   Multi-processing modules are designed to work behind the scenes and do
   not interfere with requests in any way. In fact, its only function is
   to map the request to a thread or process. One advantage of this
   technique is that each MPM can define its own directives. This means
   that if you are using a PREFORK MPM, you won't be asked how many
   threads you want per server, or if you are using the WINNT MPM, you
   won't need to specify the number of processes.

                         Will Apache 1.3 Modules work?

   Modules written for 1.3 will not work with 2.0 without modification.
   There are many changes which will be documented by the time 2.0 is
   released.

   In Apache 1.3, each module uses a table of callback routines and data
   structures. Instead of using this table to specify which functions to
   use when processing a request, 2.0 modules will have a new function to
   register any callbacks needed.

   In the past, new features have been added to subsequent releases of
   Apache which required the callback table to be expanded causing
   existing modules to break. In 2.0, each module is able to define how
   many callbacks it wants to use instead of using a statically defined
   table with a set number of callbacks. If the Apache Group decides to
   add callbacks in the future, the changes are less likely to affect
   existing modules.

   Many things have been abstracted in Apache 2.0 and there are many new
   functions available. This means it will no longer be possible to
   access most of the internals of Apache data structures directly. For
   example, if a module needs access to the connection in order to send
   data to the client, it will have to use the provided functions rather
   than access the socket directly.

                      The Apache Portable Run-Time (APR)

   APR was originally designed as a way to combine code across platforms.
   There are some sections of code that should be different for different
   platforms as well as sections of code that can safely be made common
   across all platforms.

   Apache on Windows currently uses POSIX functions and types that are
   non-native and non-optimised for communicating across a network. By
   replacing these functions and types with the Windows native equivalent
   there has been a significant performance improvement. For example,
   spawning CGI processes is very confusing in Apache 1.3 because Unix,
   Windows, and OS/2 all handle spawning in different ways. By using APR,
   the logic can be combined for spawning CGI processes, decreasing the
   number of platform-specific bugs that are introduced later.

   APR will make porting Apache to additional platforms easier. With a
   fully implemented APR layer any platform will be able to run Apache.
   APR is small and well defined and once it is fully integrated into
   Apache, will change very little in the future. Apache has never been
   well defined for porting purposes as there was too much code to make
   porting a simple task. In addition, the code was originally designed
   for use on Unix, which made porting to non-POSIX platforms very
   difficult. With APR, all a developer needs to do is implement the APR
   layer. APR was designed with Windows, Unix, OS/2, and BeOS in mind and
   is more flexible as a result.

   APR acts as the abstraction layer in Apache 2.0. To allow the use of
   native types for the best performance, APR has unified functions such
   as sockets into a single type which Apache will then use independently
   of the platform. The underlying type is invisible to the Apache
   developer, who is free to write code without worrying about how it
   will work on multiple platforms.

                               When, When, When?

   Apache 2.0 is a major re-working of Apache that will hopefully result
   in a web server that can continue to grow and serve the web. As has
   been traditional with previous Apache releases, the 2.0 upgrade will
   be made available when it is ready and stable. There is no promised
   release date although it is hoped that a beta version will be
   available either late in 1999 or early in 2000.

   This article covers some of the major changes in Apache 2.0, such as
   MPMs, module callbacks, and the abstraction layer. Future editions of
   Apache Week will report on the progress of Apache 2.0 and highlight
   any major developments.

     _________________________________________________________________

   Comments or criticisms? Please email us at [12]editors@apacheweek.com.

   [13]Apache Week is copyright 1996-1999 by [14]C2Net Europe Limited.

--
※ 来源:·BBS 水木清华站 bbs.net.tsinghua.edu.cn·[FROM: 202.119.37.7]
--
※ 转载:.BBS 荔园晨风站 bbs.szu.edu.cn.[FROM: 192.168.1.144]


[回到开始] [上一篇][下一篇]

荔园在线首页 友情链接:深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店