MPMs and Future Directions

["Spinka, Kristofer" <ks...@style.net>]

  To all whom it may concern,

  I realize that some, or all, of this may have been addressed time and
time again, but I would like to query the current contributors and
direction setters at large and present.  Yes, this is only one
micro-facet of industry problems, but it is also one which is very
important at present.  I welcome any comments and/or corrections.

1. I have noticed that many MPMs attempt to be portable.  While this is
a convenience is it done at the expense of performance?  Are there more
modern MPMs in the works?  What's the status of "The Async Apache Server
implemented in terms of APR"?

2. As the various Unix like OS's continue to mature, and the "Unix-like"
standards do not keep pace, these OS's begin to diverge more and more,
especially internally.  There are situations where ad hoc
standardization has occurred (i.e. sendfile(), /dev/poll), but to a
limited degree (i.e. Linux /dev/epoll, FreeBSD kqueue, sendfile()).
While Dan Kegel continues to make the world at large aware of the
importance of a scalable I/O readiness mechanism, it would appear that
some of us are not taking enough stabs.

3. Platform spotlights.  I know it is probably inappropriate to
emphasize the importance of improving one platform over another, but we
certainly don't lose any sleep over porting Apache to DOS.  The point
here is that reality dictates that certain platforms do in fact have a
significantly greater presence as web servers than others.  My offhand
list, in no particular order, is Solaris, Linux, {Free,Net}BSD, and
Windows.

4. Tomorrow's view.  While Apache has the strongest presence, according
to popular statistics firms, Microsoft IIS is no slouch.  In fact, they
appear to have nearly half of Apache's penetration.  On April 24th,
Microsoft plans to release IIS 6, a significant overhaul in many
regards, especially performance.  The development personnel at Microsoft
have apparently put a significant effort into re-architecting IIS,
following, in principle, what several Unix like OS's have tried (i.e.
tux, nca).  The fact alone that Windows does not *need* to comply with
any intra-platform standards does give it a level agility that can only
be obtained in the Apache world through platform specific optimizations.
This does not mean that interfaces cannot be standardized, it's just a
point.  In addition, I would just like to point out, that the
performance aspect of IIS 6 is *not* even the top bullet on the list.
While Microsoft may have significant monetary resources, they are using
the same Intel processors that everyone does.

5. Unix-like OS's integration of Apache.  It has become quite evident
that the majority of Unix-like OS's have adopted Apache as their
"default" web server.  This, of course, is good news; it signifies that
Apache has caught their attention.  However, it has also placed a
significant amount of faith in Apache.  Screenshots do for a GUI what
web server software does for an Internet server; meaning that it is a
cover by which the book is judged.

6. Documentation.  I realize that it's the least fun thing for many of
us, but it does attract newcomers.  While I have no doubt the current
Apache team is superb, new blood for thinkers and workers is always
important.  Without a captive, sexy way to draw someone into the labor
of learning the internals of 
Apache it will never happen on a large scale.

7. More to come in the future.  Apache is great, keep up the awesome
work, we all appreciate it!

    /kristofer

RE: MPMs and Future Directions

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 02:01 AM 3/28/2003, you wrote:
>> >6. Documentation.
>
>I was referring to documentation for developers, is this not the place
>http://httpd.apache.org/docs-2.0/developer/ ?  If it is the correct
>place it just seems a bit sparse.

Missed that!  Yes, as much as I'm certain the docs team might 
want to facilitate translations and so forth, we should begin the same
level of effort at doxygenation of Apache itself, at least the externals :-)

Many of those developer docs, though, are the product of one coder
having to wade through Apache and deciding to write down exactly
what it's doing.  Feel free to contribute documents about specific
behaviors or features of the API, because doxygen doesn't do well
for capturing the 'whys' or overall structure.

Bill

Re: MPMs and Future Directions

[Jeff Trawick <tr...@attglobal.net>]

Spinka, Kristofer wrote:
>>>6. Documentation.
>>
>>Apparently you are entirely unaware of the docs@httpd.apache.org team,
>>and the fact that Apache's documentation is generally regarded as one
>>of the better sets of open source docs?
>>
>>  http://httpd.apache.org/docs-project/
> 
> 
> I was referring to documentation for developers, is this not the place
> http://httpd.apache.org/docs-2.0/developer/ ?  If it is the correct
> place it just seems a bit sparse.

Use the source.  There has never been extensive, official Apache 
developer documentation, yet there are large numbers of modules for 
Apache.  Successful Apache module developers are accustomed to looking 
at the sources of the modules provided with Apache, and open source 3rd 
party modules, to know how to best use the Apache API.

RE: MPMs and Future Directions

["Spinka, Kristofer" <ks...@style.net>]

> >6. Documentation.
> 
> Apparently you are entirely unaware of the docs@httpd.apache.org team,
> and the fact that Apache's documentation is generally regarded as one
> of the better sets of open source docs?
> 
>   http://httpd.apache.org/docs-project/

I was referring to documentation for developers, is this not the place
http://httpd.apache.org/docs-2.0/developer/ ?  If it is the correct
place it just seems a bit sparse.

  /kristofer

Re: MPMs and Future Directions

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 01:25 AM 3/28/2003, Spinka, Kristofer wrote:
>  I realize that some, or all, of this may have been addressed time and
>time again, but I would like to query the current contributors and
>direction setters at large and present.  Yes, this is only one
>micro-facet of industry problems, but it is also one which is very
>important at present.  I welcome any comments and/or corrections.
>
>1. I have noticed that many MPMs attempt to be portable.  While this is
>a convenience is it done at the expense of performance?

The most portable will be the most used MPM, and therefore the most
bug-free.  Examples are prefork and worker.

Less portable but high demand include winnt (required for Windows) and
the perchild.  Others are on the drawing board.

>Are there more modern MPMs in the works?  What's the status of 
>"The Async Apache Server implemented in terms of APR"?

Realize that an Async server, compared to IIS isn't happening anytime
soon.  However, we already have code on the drawing boards that 
implements the pre-, intra- and post-connection phases in async.
The problem is that once the *request* goes async, we invalidate all
of the existing handlers and other plug-in modules.  That won't happen
for a while yet.

It's being implemented in terms of MPMs - nobody is ready to try to
plug in all the different flavors of async support into APR just yet.

I wouldn't be surprised if the group announces a semi-Async MPM
beyond Win32 for the Apache 2.2 release.  But I expect them to be
pretty platform-specific for a while, yet.  It will probably be easier
to develop them independently of APR, and then try to capture that
greatest common denominator as an APR api.

>3. Platform spotlights.  [...] My offhand list, in no particular order, 
>is Solaris, Linux, {Free,Net}BSD, and Windows.

Sounds like the list we already pay the most attention to.  Simple
fact: if no developers run the OS - it's features aren't exploited and
it isn't as well tested.  So figure developers OS's roughly equal the
'real world', so this has never been an issue.

None the less, OS2, Netware, BeOS, HP/UX, TPF and other ports 
persist in being rather well supported.  Go figure :-)

>6. Documentation.

Apparently you are entirely unaware of the docs@httpd.apache.org team,
and the fact that Apache's documentation is generally regarded as one
of the better sets of open source docs?

  http://httpd.apache.org/docs-project/

The other points seemed to be opinion or commentary, as opposed
to soliciting a response.  I hope I answered your key questions.

Bill