[apache-talk] ????? ???-?? ?? ??????: Fw: Apache Week issue 173 (24th September 1999)

["Vladimir Bormotov" <bor@xxxxxxxxxxxxxx>]

----- Original Message -----
From: Apache Week <mark@xxxxxxxxxxxxxx>
To: <apacheweek@xxxxxxxxxxxxxx>
Sent: 24 сентября 1999 г. 18:38
Subject: Apache Week issue 173 (24th September 1999)


> This is the latest edition of Apache Week. To read this issue or any
> past issues, see  http://www.apacheweek.com/
> ----------------------------------------------------------------------
>
>        [1]Advert: See us at e-business expo 99 in London 2-4 Nov 1999
>
>    _[2]Apache Week Home | [3]Features | [4]Apache 1.3.4 | [5]Other Issues
>                                       _
>                                 APACHE WEEK
>
> The essential weekly guide for users of the world's most popular Web
server.
>
>                        Issue 173: 24th September 1999
>
>      Over the last few months, we've received many queries about why
>      Apache Week had little to report of Apache 1.3 development. Most of
>      the Apache developers have been hard at work writing the next
>      generation of Apache, version 2.0. This week, developer [6]Ryan
>      Bloom takes time out to summarise the story so far.
>
>      _In this special issue_
>      * [7]Apache 2.0: The Next Generation
>      * [8]Multiple-Processing Modules (MPM)
>      * [9]Will Apache 1.3 Modules work?
>      * [10]The Apache Portable Run-Time (APR)
>      * [11]When, When, When?
>
>                         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@xxxxxxxxxxxxxxx
>
>    [13]Apache Week is copyright 1996-1999 by [14]C2Net Europe Limited.
>
> References
>
>    1. http://www.apacheweek.com/ads/?n=ebiz99&do=go
>    2. http://www.apacheweek.com/
>    3. http://www.apacheweek.com/features/
>    4. http://www.apacheweek.com/features/guide13
>    5. http://www.apacheweek.com/issues/
>    6. http://www.apache.org/contributors/#bloom
>    7. http://www.apacheweek.com/issues/current#apache20
>    8. http://www.apacheweek.com/issues/current#mpm
>    9. http://www.apacheweek.com/issues/current#modules
>   10. http://www.apacheweek.com/issues/current#apr
>   11. http://www.apacheweek.com/issues/current#release
>   12. mailto:editors@xxxxxxxxxxxxxx
>   13. http://www.apacheweek.com/
>   14. http://www.eu.c2.net/
>
>
> ------------------------------------------------------------------------
> To stop receiving Apache Week, send a message to majordomo@xxxxxxxxxxxxxx
> containing the text
> unsubscribe apacheweek
>

=============================================================================
=               Apache-Talk@xxxxxxxxxxxxx mailing list                      =
Mail "unsubscribe apache-talk" to majordomo@xxxxxxxxxxxxx if you want to quit.
=       Archive avaliable at http://www.lexa.ru/apache-talk                 =