You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Paul Querna <ch...@force-elite.com> on 2005/12/03 20:36:10 UTC
What do you want in HTTPD 2.4/3.0/X/GREEN?
My intention is for this to be a wide open brainstorming thread.
I expect that we will be able to discuss several ideas in much more
detail at the Hackathon next week, but I really want to get all ideas
'on the table'.
I have a few things I would like to see, but I am sure there are perhaps
hundreds of other major features that other people want. It helps to
know what everyone else is thinking about new features, rather than one
person going off an doing it all by themselves. (not that I'll stop
anyone from that either).
Here is my list:
* Async/Event MPM: Complete Async pipeline for static files. I believe
we can seriously give every existing single-threaded-event-based server
a run for their money on every existing benchmark. Toss in some dynamic
content, and a hybrid Event/Worker has serious potential. Some of this
work is ongoing in the async-read dev branch, but there is plenty more
to do.
* A Perchild MPM/replacement: The SoC perchild-replacement project
didn't work out. We have a basic design that is sound, but we need to
actually write the code.
* HTTP Removed from the core: I would like to be able to build with
--disable-http. Sounds crazy, but it will hopefully shrink the core, and
help us improve other protocol handlers like mod_ftp and mod_smtpd.
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Paul Querna <ch...@force-elite.com>.
Justin Erenkrantz wrote:
> --On December 3, 2005 8:52:38 PM +0000 Colm MacCarthaigh
> <co...@stdlib.net> wrote:
>
>> * A threaded MPM to become the default: I would like mod_cgid
>
> How about making the MPMs DSOable?
++1!!!!!!!!!
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On December 3, 2005 8:52:38 PM +0000 Colm MacCarthaigh <co...@stdlib.net>
wrote:
> * A threaded MPM to become the default: I would like mod_cgid
How about making the MPMs DSOable?
> * Build upon the aaa framework to do some more useful things. Two
> in particular I'd like, but they are awkward and contentious.
> First, is that we have a lot of third-party providers coming up
> with ways of storing state for authentication via http. Most
> often via cookies, but sometimes via url-encoded session ID's
> and so on. It's messy and ugly, but ignoring the reality of
> One-Time Passwords isn't good either, so it might be justifiable
> to come with a framework for a united approach. Making say
> mod_authnz_secureid only a small bit of work.
>
> The other thing I think is missing from the aaa framework is
> a way for an admin to mandate that aaa happen over an encrypted
> session only. Some magic directive that doesn't extend into
> per-dir/htaccess land that helps them out a little in making
> sure that https is being used.
Huh. Cool. I'd like to hear more about this... -- justin
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Sat, Dec 03, 2005 at 11:36:10AM -0800, Paul Querna wrote:
> * Async/Event MPM: Complete Async pipeline for static files. I believe
> we can seriously give every existing single-threaded-event-based server
> a run for their money on every existing benchmark. Toss in some dynamic
> content, and a hybrid Event/Worker has serious potential. Some of this
> work is ongoing in the async-read dev branch, but there is plenty more
> to do.
>
> * A Perchild MPM/replacement: The SoC perchild-replacement project
> didn't work out. We have a basic design that is sound, but we need to
> actually write the code.
>
> * HTTP Removed from the core: I would like to be able to build with
> --disable-http. Sounds crazy, but it will hopefully shrink the core, and
> help us improve other protocol handlers like mod_ftp and mod_smtpd.
Ideas based on prior discussions and personal desires;
* A threaded MPM to become the default: I would like mod_cgid
to die, and for there to be a mod_execd, with an optional ap_exec()
provider. Every place that would have a fork()/exec() can then use
some ap_ function which takes an environment pointer (or NULL for
unchanged), some structure for option suexec stuff, and returns
filehandles for out/in/err. On non-unix/non-threaded it's a noop or
just forks and exec. On threaded, we use a mod_execd (possible with
pre-forking) and pass file descriptors over a local socket.
Weed out other thread-safety nits like the lexx/yacc generated
stuff.
* Configurable buffer sizes; This work is really in apr, and some of
it is done, but buckets need to be tackled next and then it needs to
be hacked in-httpd. But it would be nice to be able to configure the
buffer size used for reading files, both when we read() them and
when we call sendfile() on them, because that's how we get to
scalable TCP flows. Setting "txqueuelen" on an interface isn't much
use without application support for buffering similar ammounts - but
that's what admins are starting to need with the ultra-large
Window-sizes neccessary to get really good flow-performance out of
say a 10G link.
* A small protocol module that lets an admin interface apache via
a unix domain socket. To give the admin an out-of-band channel to
query mod_status when their link is full, or when they've gracefully
stopped.
* Optional XML-ised output for things like mod_status
* Build upon the aaa framework to do some more useful things. Two
in particular I'd like, but they are awkward and contentious.
First, is that we have a lot of third-party providers coming up
with ways of storing state for authentication via http. Most
often via cookies, but sometimes via url-encoded session ID's
and so on. It's messy and ugly, but ignoring the reality of
One-Time Passwords isn't good either, so it might be justifiable
to come with a framework for a united approach. Making say
mod_authnz_secureid only a small bit of work.
The other thing I think is missing from the aaa framework is
a way for an admin to mandate that aaa happen over an encrypted
session only. Some magic directive that doesn't extend into
per-dir/htaccess land that helps them out a little in making
sure that https is being used.
Some of those I have concrete ideas on and plan to code away at, others
are a bit nebulous :)
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Mads Toftum <ma...@toftum.dk>.
On Sun, Dec 04, 2005 at 12:31:31AM +0100, Astrid 'Kess' Keßler wrote:
> hm, together with a perchild-like mpm I could imagine a memory limitation per
> child process ...
>
Not really necessary given that the whole point of a perchild-like mpm
is to run vhosts under different user ids, so it should be fairly simple
to handle that at the os level.
vh
Mads Toftum
--
`Darn it, who spiked my coffee with water?!' - lwall
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Astrid 'Kess' Keßler <ke...@kess-net.de>.
On Sunday 04 December 2005 00:14, Justin Erenkrantz wrote:
> --On December 4, 2005 12:06:40 AM +0100 Joost de Heer
>
> <jo...@sanguis.xs4all.nl> wrote:
> > "This applies to processes forked off from Apache children servicing
> > requests, not the Apache children themselves."
> >
> > So not exactly what I proposed, unless I am understanding that wrong?
>
> If you want to limit the children themselves, then you want the standard
> ulimit controls available in your shell or whatnot. -- justin
hm, together with a perchild-like mpm I could imagine a memory limitation per
child process ...
kess
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Sun, Dec 04, 2005 at 10:30:34AM +0100, Joost de Heer wrote:
> >>"This applies to processes forked off from Apache children servicing
> >>requests, not the Apache children themselves."
> >>
> >>So not exactly what I proposed, unless I am understanding that wrong?
> >
> >
> >If you want to limit the children themselves, then you want the standard
> >ulimit controls available in your shell or whatnot. -- justin
>
> Because I want other processes to be able to grow larger than 20 MB. Would
> be a rather useless database if it was limited to 20 MB memory....
Huh?
You can set the ulimit for the duration of your httpd start up script.
# (ulimit -m 256; ./apachectl start)
The unit of measure for the ulimit command differs based on OS. -- justin
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Joost de Heer <jo...@sanguis.xs4all.nl>.
>> "This applies to processes forked off from Apache children servicing
>> requests, not the Apache children themselves."
>>
>> So not exactly what I proposed, unless I am understanding that wrong?
>
>
> If you want to limit the children themselves, then you want the standard
> ulimit controls available in your shell or whatnot. -- justin
Because I want other processes to be able to grow larger than 20 MB. Would be
a rather useless database if it was limited to 20 MB memory....
Joost
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On December 4, 2005 12:06:40 AM +0100 Joost de Heer
<jo...@sanguis.xs4all.nl> wrote:
> "This applies to processes forked off from Apache children servicing
> requests, not the Apache children themselves."
>
> So not exactly what I proposed, unless I am understanding that wrong?
If you want to limit the children themselves, then you want the standard
ulimit controls available in your shell or whatnot. -- justin
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Joost de Heer <jo...@sanguis.xs4all.nl>.
Justin Erenkrantz wrote:
> --On December 3, 2005 11:57:08 PM +0100 Joost de Heer
> <jo...@sanguis.xs4all.nl> wrote:
>
>> An idea, although I have no idea whether this can be done at all, or
>> whether this has been discussed before:
>>
>> MaxMemoryPerChild.
>
>
> <http://httpd.apache.org/docs/2.2/mod/core.html#rlimitmem>
"This applies to processes forked off from Apache children servicing requests,
not the Apache children themselves."
So not exactly what I proposed, unless I am understanding that wrong?
Joost
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On December 3, 2005 11:57:08 PM +0100 Joost de Heer
<jo...@sanguis.xs4all.nl> wrote:
> An idea, although I have no idea whether this can be done at all, or
> whether this has been discussed before:
>
> MaxMemoryPerChild.
<http://httpd.apache.org/docs/2.2/mod/core.html#rlimitmem>
HTH. -- justin
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Joost de Heer <jo...@sanguis.xs4all.nl>.
An idea, although I have no idea whether this can be done at all, or whether
this has been discussed before:
MaxMemoryPerChild.
Especially with things like PHP, occasionally a child process can 'explode'
and grow very large. As far as I'm aware, the only way to limit child
processes is currently the number of requests. But since it's rather hard to
predict when a child can grow very large (it theoretically could happen in the
first request), I'd rather have a memory limit: Once a child process grows
beyond that limit, kill the child (after the current request finishes of course).
I've had boxes where the average child was 12 MB, but once in a while, a child
would grow upto 140MB. Normally, MaxClients of 70 would be quite safe, but
with the growing children, even that was too high. But if I could set
MaxMemoryPerChild 20 MB, this would be no problem, as these children would be
killed before they grew too large.
Joost
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Paul Querna <ch...@force-elite.com>.
William A. Rowe, Jr. wrote:
> Nick Kew wrote:
>> On Saturday 03 December 2005 19:36, Paul Querna wrote:
>>
>>> My intention is for this to be a wide open brainstorming thread.
>>
>> But we don't have a track record of round tuits.
>
> Sort of the reason the thread is interesting, but I'd rather see code
> to comment on. Interesting ideas, I have some that I'd rather share
> as code once they are ready.
Thats the part of the point of this thread. To get the other developers
interested in your ideas, so that the code can be done sooner.
-Paul
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Nick Kew wrote:
> On Saturday 03 December 2005 19:36, Paul Querna wrote:
>
>>My intention is for this to be a wide open brainstorming thread.
>
> But we don't have a track record of round tuits.
Sort of the reason the thread is interesting, but I'd rather see code
to comment on. Interesting ideas, I have some that I'd rather share
as code once they are ready.
Bill
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Nick Kew <ni...@webthing.com>.
On Saturday 03 December 2005 19:36, Paul Querna wrote:
> My intention is for this to be a wide open brainstorming thread.
>
> I expect that we will be able to discuss several ideas in much more
> detail at the Hackathon next week, but I really want to get all ideas
> 'on the table'.
Alas, I shall be remote.
> Here is my list:
>
> * Async/Event MPM:
Sounds fine for a 2.4.
> * A Perchild MPM/replacement:
Ditto. But we don't have a track record of round tuits.
> * HTTP Removed from the core:
Probably a 3.0 thing. What's the request_rec - and everything that
revolves around it - going to look like?
One thing we really should avoid is another big API break like 1.x-2.x.
Third-party modules should continue to work with little or no rewriting.
Some more thoughts;
* Authz cleanup (already started in authz-dev)
* Flexible handlers using ap_provider
c.f. http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=112843906920434&w=2
* Configuration revamp - enable reconfiguration (ideally per-vhost)
without a server restart.
--
Nick Kew
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Alexander Lazic <al...@none.at>.
Hi,
On Sam 03.12.2005 11:36, Paul Querna wrote:
>My intention is for this to be a wide open brainstorming thread.
>
>I expect that we will be able to discuss several ideas in much more
>detail at the Hackathon next week, but I really want to get all ideas
>'on the table'.
my whish is very simple:
Bugfix the open bugs at:
http://issues.apache.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Apache+httpd-2&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0=
432 bugs found.
What should be to define:
1.) Are all of these Bugs?
2.) How 'easy' can be a bug fixed?
3.) Which bugs are feature requests and how important is it for the
'user'?
I hope some one of the know developer/organisator think also ;-)
jm2c
greetings
Alex
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Matthieu Estrade <me...@apache.org>.
Paul Querna wrote:
> My intention is for this to be a wide open brainstorming thread.
>
> I expect that we will be able to discuss several ideas in much more
> detail at the Hackathon next week, but I really want to get all ideas
> 'on the table'.
>
> I have a few things I would like to see, but I am sure there are
> perhaps hundreds of other major features that other people want. It
> helps to know what everyone else is thinking about new features,
> rather than one person going off an doing it all by themselves. (not
> that I'll stop anyone from that either).
>
> Here is my list:
>
> * Async/Event MPM: Complete Async pipeline for static files. I
> believe we can seriously give every existing
> single-threaded-event-based server a run for their money on every
> existing benchmark. Toss in some dynamic content, and a hybrid
> Event/Worker has serious potential. Some of this work is ongoing in
> the async-read dev branch, but there is plenty more to do.
>
> * A Perchild MPM/replacement: The SoC perchild-replacement project
> didn't work out. We have a basic design that is sound, but we need to
> actually write the code.
A perchild (threaded) mpm would be really interesting considering all
the shared memory issues we have because of the fork/thread mpm.
Doing some caching, session tracking become difficult and not really
stable on some plateform with the shared memory.
>
> * HTTP Removed from the core: I would like to be able to build with
> --disable-http. Sounds crazy, but it will hopefully shrink the core,
> and help us improve other protocol handlers like mod_ftp and mod_smtpd.
>
I agree, we have a famous core, which could be useful for many others
protocol, but actually, it still depend too much on http. I remember my
poc for mod_smtpd project, still many include or file related to http.
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Olaf van der Spek <ol...@gmail.com>.
On 12/4/05, Ian Holsman <li...@holsman.net> wrote:
> Garrett Rooney wrote:
> > On 12/3/05, Ian Holsman <li...@holsman.net> wrote:
> >
> >> I'd also like to brainstorm a better solution to running Rails/Django
> >> applications inside of the httpd process than the SCGI/FastCGI solution
> >> which most people use.
> >
> > Out of curiosity, what do you think is wrong with the current FastCGI
> > method of running them?
> >
>
> configuration.
> for example in order for me to get typo running on my blog, I need 4
> rewrite rules. (and when I tried to do something slightly different, it
> took me a good hour to configure it properly with all the rewrite magic)
Wouldn't it be better to fix/improve the configuration?
Why should/would an 'in-process' request processor be easier to
configure than an out-of-process one?
Not all things can run inside httpd and for PHP I think it'd also be
nice if it ran outside.
> also when applications 'experts' like scott (the creator of typo) have
> issues like
> http://scottstuff.net/blog/articles/2005/07/20/apache-tuning-for-rails-and-fastcgi
>
> i think it isn't easy enough to run.
> what I am after is something as simple as
>
>
> RailsApp /foo/ rails-controller.rb [cache] [ENV=production]
>
>
> which would just work as a in-process application...
> making it as simple as running a PHP application is the goal.
>
> I don't like the trend i see with rails & django people saying apache is
> hard to use and switching to other web servers.
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Ian Holsman <li...@holsman.net>.
Garrett Rooney wrote:
> On 12/3/05, Ian Holsman <li...@holsman.net> wrote:
>
>> I'd also like to brainstorm a better solution to running Rails/Django
>> applications inside of the httpd process than the SCGI/FastCGI solution
>> which most people use.
>
> Out of curiosity, what do you think is wrong with the current FastCGI
> method of running them?
>
configuration.
for example in order for me to get typo running on my blog, I need 4
rewrite rules. (and when I tried to do something slightly different, it
took me a good hour to configure it properly with all the rewrite magic)
also when applications 'experts' like scott (the creator of typo) have
issues like
http://scottstuff.net/blog/articles/2005/07/20/apache-tuning-for-rails-and-fastcgi
i think it isn't easy enough to run.
what I am after is something as simple as
RailsApp /foo/ rails-controller.rb [cache] [ENV=production]
which would just work as a in-process application...
making it as simple as running a PHP application is the goal.
I don't like the trend i see with rails & django people saying apache is
hard to use and switching to other web servers.
> -garrett
>
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 12/3/05, Ian Holsman <li...@holsman.net> wrote:
> I'd also like to brainstorm a better solution to running Rails/Django
> applications inside of the httpd process than the SCGI/FastCGI solution
> which most people use.
Out of curiosity, what do you think is wrong with the current FastCGI
method of running them?
-garrett
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Henri Gomez <he...@gmail.com>.
Support a sort of dynamic configuration via an admin console, ie
adding / removing proxy directives.
2005/12/5, Brad Nicholes <BN...@novell.com>:
>
>
> >>> On 12/3/2005 at 5:07 pm, in message
> <43...@holsman.net>,
> lists@holsman.net wrote:
>
> > Configuration .. make it configurable. by that I mean allowing people
> to
> > use LDAP or a DB to hold the configuration files, and not a flat
> file.
> > This is mainly intended for large server farms. Currently the main
> > reason for logging onto a webserver is to change it's configuration
> (and
> > bounce) .. if we could reduce that to just 'bounce' it might make
> life
> > easier. (or some method where it checks configs every X minutes and
> > autobounces..removing the need to log onto the machine at all ;-)
> >
> > Configuration .. make it easier..I can't think of anything on how to
> do
> > this off the top of my head, but it seems to be a common complaint.
> >
>
> Take a look at
> http://forge.novell.com/modules/xfmod/project/?apache_manager . It
> was designed as a cross-platform/any apache version admin tool that uses
> LDAP as the configuration store.
>
> Brad
>
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 12/3/2005 at 5:07 pm, in message
<43...@holsman.net>,
lists@holsman.net wrote:
> Configuration .. make it configurable. by that I mean allowing people
to
> use LDAP or a DB to hold the configuration files, and not a flat
file.
> This is mainly intended for large server farms. Currently the main
> reason for logging onto a webserver is to change it's configuration
(and
> bounce) .. if we could reduce that to just 'bounce' it might make
life
> easier. (or some method where it checks configs every X minutes and
> autobounces..removing the need to log onto the machine at all ;-)
>
> Configuration .. make it easier..I can't think of anything on how to
do
> this off the top of my head, but it seems to be a common complaint.
>
Take a look at
http://forge.novell.com/modules/xfmod/project/?apache_manager . It
was designed as a cross-platform/any apache version admin tool that uses
LDAP as the configuration store.
Brad
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Wed, Dec 07, 2005 at 11:01:35AM -0800, Brandon Fosdick wrote:
> Would it be possible to use something like fam (or kqueue on FreeBSD) and
> have httpd notified whenever the config file changes?
We could do the SIGIO trick which diablo does on BSD, though the problem
there is that on other platform we'd end up with a tight stat() loop. It
can be pretty dangerous aswell though :/
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Brian Candler <B....@pobox.com>.
On Wed, Dec 07, 2005 at 02:52:44PM -0500, Jim Jagielski wrote:
> Yeah, maybe it's time to re-open this discussion... previously,
> whenever we thought about adding more "functionality" to
> the config file, it was discouraged because it increases the
> complexity of Apache for something that could more easily be
> done via an external process (ie: a script that reads in LDAP
> info and autogens a "normal" httpd.conf file)...
The latter idea doesn't scale particularly well though. e.g. if you have
100,000 virtual hosts then
(a) you have to regenerate the whole config file every time any single one
is changed; and
(b) Apache has to reload the whole 100K vhosts every time it's changed.
The rate at which a reload is requested goes up with the number of virtual
hosts, and the work taken for each reload (in terms of database search and
Apache reconfig) also goes up with the number of virtual hosts. So you have
an N^2 scaling problem, and eventually get bogged down doing reloads and
nothing else.
You could argue the same is true if you're constantly reading configs
dynamically (e.g. mod_rewrite). However then the work is proportional to the
number of requests, not the number of vhosts. In practice, out of 100,000
vhosts, I'd be surprised if 5,000 were actually serving any significant
number of pages. It's amazing how many people pay for web hosting when
nobody looks at their pages :-)
Regards,
Brian.
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 7, 2005, at 2:01 PM, Brandon Fosdick wrote:
>> Configuration .. make it configurable. by that I mean allowing
>> people to
>> use LDAP or a DB to hold the configuration files, and not a flat
>> file.
>> This is mainly intended for large server farms. Currently the main
>> reason for logging onto a webserver is to change it's
>> configuration (and
>> bounce) .. if we could reduce that to just 'bounce' it might make
>> life
>> easier. (or some method where it checks configs every X minutes and
>> autobounces..removing the need to log onto the machine at all ;-)
>
> Would it be possible to use something like fam (or kqueue on
> FreeBSD) and
> have httpd notified whenever the config file changes? That would solve
> part of the above desire without requiring the extensive changes
> needed to
> go to a db/ldap system.
>
> OTOH, what if config loading was handled by a provider module that
> could
> then fetch the info from a file, db, ldap, whatever...
>
Yeah, maybe it's time to re-open this discussion... previously,
whenever we thought about adding more "functionality" to
the config file, it was discouraged because it increases the
complexity of Apache for something that could more easily be
done via an external process (ie: a script that reads in LDAP
info and autogens a "normal" httpd.conf file)...
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Ruediger Pluem <rp...@apache.org>.
On 12/07/2005 08:18 PM, Brandon Fosdick wrote:
>>Brandon Fosdick wrote:
[..cut..]
>
> And, to me at least, it seems Intuitively Correct that an app should be
> watching it's own config files for changes and then responding
> appropriately. I see this as being in the same vein as re-reading config
-1 on this from my administrators perspective.
I don't want the application to reload its configuration only because I adjusted
it. Adjusting and reloading configuration are two different processes and applications
that try to be "smart" in these situations are prone to mess things up in my experience.
I have many situations where I adjust the configuration and where I want it
to be reloaded at a *very* specific point of time that is well coordinated with other activities
on an environment. Additionally saving of the config files in vi during editing it
would result in a reload of the configuration with all its consequences *shiver*.
Furthermore this job would be more complicated and painful as it looks at first glance as
httpd would not only has to monitor the httpd.conf file but all included files also to make this work.
[..cut..]
Regards
Rüdiger
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 7, 2005, at 3:04 PM, Joost de Heer wrote:
>>> That could be external to httpd. Just have a monitor (or in
>>> cfengine,
>>> or whatever) that when the config changes it issues a graceful
>>> restart.
>>> Simple and straight-forward.
>
> Oops, I made a typo, and pressed save..... poof there goes my website!
>
> IMO, it's a bad idea to automagically restart when the config changes.
>
Big +1.
If someone wants some sort of external process to do this,
well, then, that's their choice. But I would be a big -1
to have Apache do this itself.
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Brandon Fosdick <bf...@bfoz.net>.
Joost de Heer wrote:
>>> That could be external to httpd. Just have a monitor (or in cfengine,
>>> or whatever) that when the config changes it issues a graceful restart.
>>> Simple and straight-forward.
>
>
> Oops, I made a typo, and pressed save..... poof there goes my website!
>
> IMO, it's a bad idea to automagically restart when the config changes.
Not necessarily. For instance, the FreeBSD port installs a wrapper script that checks the validity of the config files before allowing a (re)start. It even uses httpd to do the check. So, as long as httpd uses its existing validity checker to decide whether or not to do an auto-restart your website should be fine.
Of course, that doesn't really help much if you made a typo that results in a valid config, but there's nothing to stop that now either.
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Joost de Heer <jo...@sanguis.xs4all.nl>.
>>That could be external to httpd. Just have a monitor (or in cfengine,
>>or whatever) that when the config changes it issues a graceful restart.
>>Simple and straight-forward.
Oops, I made a typo, and pressed save..... poof there goes my website!
IMO, it's a bad idea to automagically restart when the config changes.
Joost
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Brandon Fosdick <bf...@bfoz.net>.
> Brandon Fosdick wrote:
>
>> Would it be possible to use something like fam (or kqueue on FreeBSD)
>> and
>> have httpd notified whenever the config file changes? That would solve
>> part of the above desire without requiring the extensive changes needed
>> to
>> go to a db/ldap system.
>
> That could be external to httpd. Just have a monitor (or in cfengine,
> or whatever) that when the config changes it issues a graceful restart.
> Simple and straight-forward.
Certainly true, and I've even thought about doing just that. But it seems
like a relatively simple change and it would make less work for the
user/admin.
And, to me at least, it seems Intuitively Correct that an app should be
watching it's own config files for changes and then responding
appropriately. I see this as being in the same vein as re-reading config
files in response to a kill -HUP. Instead of (or in addition to)
responding to a HUP signal, the app is responding to a file change event.
Now that I think about it, watching for file events might help with log
rotation too, since a signal wouldn't have to be sent when the files are
changed.
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Brian Akins <br...@turner.com>.
Brandon Fosdick wrote:
> Would it be possible to use something like fam (or kqueue on FreeBSD) and
> have httpd notified whenever the config file changes? That would solve
> part of the above desire without requiring the extensive changes needed to
> go to a db/ldap system.
That could be external to httpd. Just have a monitor (or in cfengine,
or whatever) that when the config changes it issues a graceful restart.
Simple and straight-forward.
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Brandon Fosdick <bf...@bfoz.net>.
> Configuration .. make it configurable. by that I mean allowing people to
> use LDAP or a DB to hold the configuration files, and not a flat file.
> This is mainly intended for large server farms. Currently the main
> reason for logging onto a webserver is to change it's configuration (and
> bounce) .. if we could reduce that to just 'bounce' it might make life
> easier. (or some method where it checks configs every X minutes and
> autobounces..removing the need to log onto the machine at all ;-)
Would it be possible to use something like fam (or kqueue on FreeBSD) and
have httpd notified whenever the config file changes? That would solve
part of the above desire without requiring the extensive changes needed to
go to a db/ldap system.
OTOH, what if config loading was handled by a provider module that could
then fetch the info from a file, db, ldap, whatever...
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Ian Holsman <li...@holsman.net>.
Paul Querna wrote:
> My intention is for this to be a wide open brainstorming thread.
>
> I expect that we will be able to discuss several ideas in much more
> detail at the Hackathon next week, but I really want to get all ideas
> 'on the table'.
>
> I have a few things I would like to see, but I am sure there are perhaps
> hundreds of other major features that other people want. It helps to
> know what everyone else is thinking about new features, rather than one
> person going off an doing it all by themselves. (not that I'll stop
> anyone from that either).
>
> Here is my list:
>
> * Async/Event MPM: Complete Async pipeline for static files. I believe
> we can seriously give every existing single-threaded-event-based server
> a run for their money on every existing benchmark. Toss in some dynamic
> content, and a hybrid Event/Worker has serious potential. Some of this
> work is ongoing in the async-read dev branch, but there is plenty more
> to do.
I've always wanted to (but not had free time) to write a SEDA-type mpm.
the SEDA is slightly different to the async/event mpm in that a given
hook/filter would process multiple events/requests at the same context
switch. This is what the apr_queue stuff was initially designed for.
I'd also like to brainstorm a better solution to running Rails/Django
applications inside of the httpd process than the SCGI/FastCGI solution
which most people use.
Configuration .. make it configurable. by that I mean allowing people to
use LDAP or a DB to hold the configuration files, and not a flat file.
This is mainly intended for large server farms. Currently the main
reason for logging onto a webserver is to change it's configuration (and
bounce) .. if we could reduce that to just 'bounce' it might make life
easier. (or some method where it checks configs every X minutes and
autobounces..removing the need to log onto the machine at all ;-)
Configuration .. make it easier..I can't think of anything on how to do
this off the top of my head, but it seems to be a common complaint.
Logging/debugging .. changing the log system to use something like Log4C
for errors.. this way the module developer can easily turn on/off
various information on a live system when he is having issues.
wish I could attend the ApacheCon.. if there was a ApacheCon OZ I'd be
there ;-)
regards
Ian
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Rich Bowen <rb...@rcbowen.com>.
Paul Querna wrote:
> My intention is for this to be a wide open brainstorming thread.
>
> I expect that we will be able to discuss several ideas in much more
> detail at the Hackathon next week, but I really want to get all ideas
> 'on the table'.
Here's my list. Or at least, the partial list that comes to mind right now.
Virtual Hosts: Make them less fragile, and simpler. It's just too easy
to get vhosts wrong, and it's too hard to do dynamic vhosts. I would
love for dynamic vhosts to be simple enough that nobody would ever be
tempted to do it with mod_rewrite ever again. mod_vhost_alias does about
10% of what folks actually want.
Configuration file: Something along the lines of mod_macro built in.
Ability to set variables and use those variables in the configuration. A
simple and usable if/else syntax.
Perchild or similar.
--
Rich Bowen
rbowen@rcbowen.com
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Mads Toftum <ma...@toftum.dk>.
On Sat, Dec 03, 2005 at 11:36:10AM -0800, Paul Querna wrote:
> * A Perchild MPM/replacement: The SoC perchild-replacement project
> didn't work out. We have a basic design that is sound, but we need to
> actually write the code.
>
+1. Could you dig out a reference to the design? I kind of lost track of
where he was going with it.
For modules I'd like to see some re-ordering of what we ship in the
tarball and what we don't.
Another thing I'd like to see is the proxy refactored to use a proper http
client lib. As an added benefit, an http client lib would be useful in
creating something like CPAN for modules.
vh
Mads Toftum
--
`Darn it, who spiked my coffee with water?!' - lwall
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Ruediger Pluem <rp...@apache.org>.
On 12/08/2005 11:59 AM, Matthias Behrens wrote:
[..cut..]
> thats a pretty good feature but something that would really kick ass would
> be if the proxy would know the cpu-load of every balanceserver
>
> is it possible you could hand the cpuload throu an extra header and restore
> it to zere if <timeout> secounds without requests
This is possible. You can write your own modules that provide the load balancing
meachanism as a provider. Thus you can provide a lb provider that somehow gets
this information from the backend and uses it for its lb decisions.
[..cut..]
>
> a first step that would be very cool also would be if i could cofigure a
> server to be used for n% of all requests and change this % while runtime. so
> if a server is running wild cause of a script that is using 100% cpu for
> endless (which happens pretty often here) i could lower his loadbalancing %
> to 1% so he would not get to much requests.
You can already do this. See
http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html#enable
Regards
Rüdiger
RE: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Matthias Behrens <ma...@gulp.de>.
hi
we are using apache 2.0.55 win32 for loadbalancing with mod_proxy /
mod_rewrite
i understand there is a much easier way now with 2.2 which provides
loadbalancing depending on throughput or requestcount
thats a pretty good feature but something that would really kick ass would
be if the proxy would know the cpu-load of every balanceserver
is it possible you could hand the cpuload throu an extra header and restore
it to zere if <timeout> secounds without requests
that would be awsome. we now use an extra software to scedule between
servers
a first step that would be very cool also would be if i could cofigure a
server to be used for n% of all requests and change this % while runtime. so
if a server is running wild cause of a script that is using 100% cpu for
endless (which happens pretty often here) i could lower his loadbalancing %
to 1% so he would not get to much requests.
thx
matthias behrens
www.gulp.de
greetings from germany
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Brian Akins <ba...@web.turner.com>.
> if it was possible, to add some statistics to the
> mod_cache, to measure the size of the cache, how well
> it is being used, as squid has its own
What I did in my "private fork" was to have stats and storage providers.
A cache stat provider provides only a single function:
apr_status_t (*update_stats)(request_rec *r, int status);
where status is a "cache code." I had several codes, but just 1 = hit
and 0 = miss may be good enough.
A cache storage basicall has a function that gets called after the
object is stored. Mine is specific to disk (as I scrapped mem in mine):
typedef struct {
const char *key;
const char *meta;
const char *data;
apr_size_t meta_size;
apr_size_t data_size;
} cache_store_t;
apr_status_t (*post_store)(request_rec *r, url_cache_store_t
Then one could store storage stats in mysql, sqlite, db, whatever.
Both used mod_status optional hook to report stats.
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Posted by Wilson Felipe <wi...@yahoo.com>.
--- Paul Querna <ch...@force-elite.com> wrote:
> My intention is for this to be a wide open
> brainstorming thread.
>
> I expect that we will be able to discuss several
> ideas in much more
> detail at the Hackathon next week, but I really want
> to get all ideas
> 'on the table'.
>
> I have a few things I would like to see, but I am
> sure there are perhaps
> hundreds of other major features that other people
> want. It helps to
> know what everyone else is thinking about new
> features, rather than one
> person going off an doing it all by themselves. (not
> that I'll stop
> anyone from that either).
if it was possible, to add some statistics to the
mod_cache, to measure the size of the cache, how well
it is being used, as squid has its own
Wilson Felipe
__________________________________________
Yahoo! DSL Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com