You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Akins, Brian" <Br...@turner.com> on 2010/06/05 00:21:01 UTC
C as config
All of you folks who have to answer user questions, go ahead and ready your
hate mail :)
I've been playing some with Varnish (long story) and lots of people seem to
like it. The config "language" (VCL) is just a thin wrapper on top of C.
Heck, you can just write C inline.
Also, I do a good bit with Lua -- in httpd and other projects. Every time I
run profiles on this stuff, Lua is always 3 out of the top 5 cpu consumers.
And lots of it is just the language itself (all the table look-ups) and we
highly optimized our method dispatches (using apr_hash, even had a version
using gperf). Now this is probably just fine for mere mortals, but it has
always bothered me. We always meant to go back and write higher level
modules based on the "low level" Lua bindings, but we never did and we have
several non programmers who are happily writing "configs" in Lua.
As a side project several months ago (maybe I mentioned it here??), I wrote
a very simple module that basically loaded small C libraries, examined their
symbol table and added certain functions to an array for each hook:
int fixups(request_rec *r) would get added to an array of functions ran at
fixups phase, etc.
I never really pursued it very far, but it was fast. Of course you had all
the C things to worry about.
So, a fellow engineer and I were talking today and convinced ourselves to
strip Lua from another project and just use C as the "high level" language.
Lots of the gory implementation was already hidden in C libraries anyway, so
it was just a matter of "porting" the Lua helpers into straight C. It took
less than 2 hours. We were sort of shocked at the results - 1/3 the memory
usage and 50% better performance (you run out of CPU eventually, no matter
what you do). Odd thing was, the code in C for the "Config" looked eerily
close to the Lua. Of course, that may be a good sign that I know nothing
about writing Lua... (And yes, we tested with luajit)
So, we thought about "wouldn't it just be cool if Apache had VCL." Then I
thought, I already know C, why do I need to learn a meta-language that just
writes C??? "Won't someone think of the users!" I could here all of the
#httpd folks saying.
Not a terribly interesting read, but we are seriously considering just using
straight C with some helper functions and macros as the "config" for one of
our projects.
And, for the record I was wrong in the past - yes, async is the answer...
--
Brian Akins
Re: C as config
Posted by Graham Leggett <mi...@sharp.fm>.
On 16 Jun 2010, at 12:49 PM, Joe Orton wrote:
> The core output filter should coalesce "small" writes already and if
> it's not doing that effeciently that's a bug. Are the "tiny" files
> you
> were seeing getting sendfile()d out bigger than AP_MIN_SENDFILE_BYTES?
> That sounds like a case for bumping up AP_MIN_SENDFILE_BYTES.
Many of the packets consisted of a CRLF followed by an indentation
tab, and were only a few bytes long. The core output filter is too
late in the chain to make any difference, as the response had already
been turned by the chunking filter into hundreds of little chunks,
consisting of a heap bucket (chunk header), followed by a file bucket
(the original content), followed by an immortal bucket (trailing
CRLF), etc.
The fix was to simply buffer up the fragmented output directly after
the fragments where created, and let the rest of the filter stack step
in and work as efficiently as possible on as few buckets as possible.
Regards,
Graham
--
Re: C as config
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Jun 16, 2010 at 12:05:21PM +0200, Graham Leggett wrote:
> On 16 Jun 2010, at 10:45 AM, Joe Orton wrote:
>
> >>There is already mod_buffer in trunk. From reading the docs, it
> >>should
> >>be suitable for this purpose. Or is it missing some functionality?
> >
> >You can get many of the benefits of using a memory buffer in the
> >output
> >filter chain very cheaply by increasing SendBufferSize, without the
> >extra overhead of an extra filter.
>
> This won't help you when you have many small file buckets, which is
> what you get when you put a forest of mod_include directives into a
> file. Each of the (in our worst case 500 or so) file buckets is
> happily sent out using SENDFILE, one after the other, in tiny chunks
> on the wire. This same problem can occur in any dynamic application
> doing a lot of small writes.
The core output filter should coalesce "small" writes already and if
it's not doing that effeciently that's a bug. Are the "tiny" files you
were seeing getting sendfile()d out bigger than AP_MIN_SENDFILE_BYTES?
That sounds like a case for bumping up AP_MIN_SENDFILE_BYTES.
Regards, Joe
Re: C as config
Posted by Graham Leggett <mi...@sharp.fm>.
On 16 Jun 2010, at 10:45 AM, Joe Orton wrote:
>> There is already mod_buffer in trunk. From reading the docs, it
>> should
>> be suitable for this purpose. Or is it missing some functionality?
>
> You can get many of the benefits of using a memory buffer in the
> output
> filter chain very cheaply by increasing SendBufferSize, without the
> extra overhead of an extra filter.
This won't help you when you have many small file buckets, which is
what you get when you put a forest of mod_include directives into a
file. Each of the (in our worst case 500 or so) file buckets is
happily sent out using SENDFILE, one after the other, in tiny chunks
on the wire. This same problem can occur in any dynamic application
doing a lot of small writes.
Regards,
Graham
--
Re: C as config
Posted by Joe Orton <jo...@redhat.com>.
On Sun, Jun 06, 2010 at 08:53:03PM +0200, Stefan Fritsch wrote:
> On Sunday 06 June 2010, Brian Pane wrote:
> > As long as the documentation explained to users that they need to
> > have enough memory to accommodate MaxClient *
> > MaxOutputBufferedPerRequest (where the latter is a hypothetical
> > name for a configurable limit on the amount of buffered output),
> > such a feature would be a net win for lots of sites.
>
> There is already mod_buffer in trunk. From reading the docs, it should
> be suitable for this purpose. Or is it missing some functionality?
You can get many of the benefits of using a memory buffer in the output
filter chain very cheaply by increasing SendBufferSize, without the
extra overhead of an extra filter.
> As an added feature, one could imagine dumping very large responses
> into a tempfile.
But not that, of course...
Regards, Joe
Re: C as config
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jun 6, 2010, at 2:53 PM, Stefan Fritsch wrote:
> On Sunday 06 June 2010, Brian Pane wrote:
>> On Sun, Jun 6, 2010 at 5:03 AM, Graham Leggett <mi...@sharp.fm>
>> wrote: [...]
>>
>>> We've also been playing with Varnish, one of the cooler things it
>>> does is have the ability to suck up an entire response into a
>>> RAM buffer and releasing the backend before playing out the
>>> response to the browser. I've looked, and we can do this pretty
>>> trivially in httpd as a simple connection filter.
>>>
>>> Very useful for expensive backends like php, instead of waiting
>>> many hundreds or thousands of milliseconds for the client to
>>> eventually close the connection before cleaning up the request
>>> pool and release php resources, you dump the response into a
>>> connection buffer, and destroy the request pool asap.
>>
>> That also would work well with the event MPM; in addition to
>> freeing up the request pool, you'd be able to free up the request
>> thread.
>>
>> As long as the documentation explained to users that they need to
>> have enough memory to accommodate MaxClient *
>> MaxOutputBufferedPerRequest (where the latter is a hypothetical
>> name for a configurable limit on the amount of buffered output),
>> such a feature would be a net win for lots of sites.
>
> There is already mod_buffer in trunk. From reading the docs, it should
> be suitable for this purpose. Or is it missing some functionality?
>
> As an added feature, one could imagine dumping very large responses
> into a tempfile.
and then sendfile() it out. The intent is that once httpd's job
is "done", release everything it can and let the OS do what
it's best at (rather than trying to replicate that within httpd, imo)
Re: C as config
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Sunday 06 June 2010, Brian Pane wrote:
> On Sun, Jun 6, 2010 at 5:03 AM, Graham Leggett <mi...@sharp.fm>
> wrote: [...]
>
> > We've also been playing with Varnish, one of the cooler things it
> > does is have the ability to suck up an entire response into a
> > RAM buffer and releasing the backend before playing out the
> > response to the browser. I've looked, and we can do this pretty
> > trivially in httpd as a simple connection filter.
> >
> > Very useful for expensive backends like php, instead of waiting
> > many hundreds or thousands of milliseconds for the client to
> > eventually close the connection before cleaning up the request
> > pool and release php resources, you dump the response into a
> > connection buffer, and destroy the request pool asap.
>
> That also would work well with the event MPM; in addition to
> freeing up the request pool, you'd be able to free up the request
> thread.
>
> As long as the documentation explained to users that they need to
> have enough memory to accommodate MaxClient *
> MaxOutputBufferedPerRequest (where the latter is a hypothetical
> name for a configurable limit on the amount of buffered output),
> such a feature would be a net win for lots of sites.
There is already mod_buffer in trunk. From reading the docs, it should
be suitable for this purpose. Or is it missing some functionality?
As an added feature, one could imagine dumping very large responses
into a tempfile.
Cheers,
Stefan
Re: C as config
Posted by Brian Pane <br...@gmail.com>.
On Sun, Jun 6, 2010 at 5:03 AM, Graham Leggett <mi...@sharp.fm> wrote:
[...]
> We've also been playing with Varnish, one of the cooler things it does is
> have the ability to suck up an entire response into a RAM buffer and
> releasing the backend before playing out the response to the browser. I've
> looked, and we can do this pretty trivially in httpd as a simple connection
> filter.
>
> Very useful for expensive backends like php, instead of waiting many
> hundreds or thousands of milliseconds for the client to eventually close the
> connection before cleaning up the request pool and release php resources,
> you dump the response into a connection buffer, and destroy the request pool
> asap.
That also would work well with the event MPM; in addition to freeing
up the request pool, you'd be able to free up the request thread.
As long as the documentation explained to users that they need to have
enough memory to accommodate MaxClient * MaxOutputBufferedPerRequest
(where the latter is a hypothetical name for a configurable limit on the
amount of buffered output), such a feature would be a net win for lots
of sites.
-Brian
Re: C as config
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jun 9, 2010, at 12:08 PM, Akins, Brian wrote:
> On 6/8/10 7:21 PM, "Graham Leggett" <mi...@sharp.fm> wrote:
>> That said, if your server doesn't have work to do, ie
>> you're just a bit-shifter, then a simple async loop will win hands down.
>
>
> We also found that even for "resource intensive" tasks -- like rendering a
> template or something similar -- it's best just to let it run so it can
> finish and get out of the way.
+1
Re: C as config
Posted by "Akins, Brian" <Br...@turner.com>.
On 6/8/10 7:21 PM, "Graham Leggett" <mi...@sharp.fm> wrote:
> That said, if your server doesn't have work to do, ie
> you're just a bit-shifter, then a simple async loop will win hands down.
We also found that even for "resource intensive" tasks -- like rendering a
template or something similar -- it's best just to let it run so it can
finish and get out of the way. Only real time it seems to make sense to
"yield" is when you need to wait on IO.* Threaded programming just hides
the wait because the OS takes care of the yielding for you. In Lua, I did
tests using coroutines to hide yielding to an even loop, and that didn't
turn out so well. The code looked awesome, but performance was horrible.
*with the popularity of RESTful (or RESTish) database-like things, writing
an application server using an event loop should be easier. No more
blocking database clients. Ultimately, that what I want to do with the Lua.
Well, that and kill mod_rewrite and the like ;)
--
Brian Akins
Re: C as config
Posted by Graham Leggett <mi...@sharp.fm>.
On 07 Jun 2010, at 11:46 PM, Akins, Brian wrote:
>> With multi-core architectures, we're finding that humble worker on
>> our
>> commodity hardware is as fast or faster than our load balancers.
>
> +1
>
> We soon found that the web servers spends more time doing context
> switches
> than actual work. (Or so it seems, probably a slight exaggeration).
> Imagine
> httpd with 100k threads!!! Now imagine the same amount of "work"
> being done
> in 2 threads. Not terribly hard to do in an asynchronous framework.
One of the php guys sent through this to us not so long ago, which
goes into the gory technical details of multicore architectures, and
precisely where you slow down and why:
http://lwn.net/Articles/250967/
It shows just how expensive context switching has become. When you
have work to do, ideally if you can get away with a simple prefork
server that shares as little as humanly possible between processes,
you get a massive increase in speed from your CPU caches, which don't
have to contend with one another.
If your code can fit completely into a CPU cache it is also a huge
win, which is is why something plain and simple like C can be so much
faster than an interpreted language (or faster than you might expect
it to be). That said, if your server doesn't have work to do, ie
you're just a bit-shifter, then a simple async loop will win hands down.
Regards,
Graham
--
Re: C as config
Posted by "Akins, Brian" <Br...@turner.com>.
On 6/6/10 8:03 AM, "Graham Leggett" <mi...@sharp.fm> wrote:
> With multi-core architectures, we're finding that humble worker on our
> commodity hardware is as fast or faster than our load balancers.
+1
We soon found that the web servers spends more time doing context switches
than actual work. (Or so it seems, probably a slight exaggeration). Imagine
httpd with 100k threads!!! Now imagine the same amount of "work" being done
in 2 threads. Not terribly hard to do in an asynchronous framework.
--
Brian Akins
Re: C as config
Posted by Graham Leggett <mi...@sharp.fm>.
On 05 Jun 2010, at 12:21 AM, Akins, Brian wrote:
> So, we thought about "wouldn't it just be cool if Apache had VCL."
> Then I
> thought, I already know C, why do I need to learn a meta-language
> that just
> writes C??? "Won't someone think of the users!" I could here all of
> the
> #httpd folks saying.
>
> Not a terribly interesting read, but we are seriously considering
> just using
> straight C with some helper functions and macros as the "config" for
> one of
> our projects.
We've also been playing with Varnish, one of the cooler things it does
is have the ability to suck up an entire response into a RAM buffer
and releasing the backend before playing out the response to the
browser. I've looked, and we can do this pretty trivially in httpd as
a simple connection filter.
Very useful for expensive backends like php, instead of waiting many
hundreds or thousands of milliseconds for the client to eventually
close the connection before cleaning up the request pool and release
php resources, you dump the response into a connection buffer, and
destroy the request pool asap.
> And, for the record I was wrong in the past - yes, async is the
> answer...
With multi-core architectures, we're finding that humble worker on our
commodity hardware is as fast or faster than our load balancers.
Regards,
Graham
--
Re: C as config
Posted by "Akins, Brian" <Br...@turner.com>.
On 6/4/10 10:37 PM, "Paul Querna" <pa...@querna.org> wrote:
> The most iteresting thing in this space since VCL was created is the
> development of LLVM & clang. It seems like if you wanted to build
> this these days, that would be where to start, though including an
> entire compiler stack does seem both a dainting task, and one that
> creates many other issues.
Yeah, I thought about that as well. However, I already know C ;) A
"config/runtime language" built using llvm could probably be just as fast as
writing straight C.
The thing I hate about VCL is that it teases you with being C like, but
without the power.
Maybe I'm just old and crufty, but C is actually easier for me than 90% of
the config languages I've seen.
--
Brian Akins
Re: C as config
Posted by Paul Querna <pa...@querna.org>.
On Jun 4, 2010, at 4:32 PM, "Akins, Brian" <Br...@turner.com>
wrote:
> On 6/4/10 7:30 PM, "Paul Querna" <pa...@querna.org> wrote:
>
>> Are you using LuaJIT 2? The performance numbers its putting up
>> seemed
>> very impressive.
>
> Yes and meh...
bummer.
The most iteresting thing in this space since VCL was created is the
development of LLVM & clang. It seems like if you wanted to build
this these days, that would be where to start, though including an
entire compiler stack does seem both a dainting task, and one that
creates many other issues.
I guess if the first approach was close to generating a .so based on a
config file input, it might be a better archtiecture.
>
> --
> Brian Akins
>
Re: C as config
Posted by "Akins, Brian" <Br...@turner.com>.
On 6/4/10 7:30 PM, "Paul Querna" <pa...@querna.org> wrote:
> Are you using LuaJIT 2? The performance numbers its putting up seemed
> very impressive.
Yes and meh...
--
Brian Akins
Re: C as config
Posted by Paul Querna <pa...@querna.org>.
On Fri, Jun 4, 2010 at 3:21 PM, Akins, Brian <Br...@turner.com> wrote:
> All of you folks who have to answer user questions, go ahead and ready your
> hate mail :)
>
> I've been playing some with Varnish (long story) and lots of people seem to
> like it. The config "language" (VCL) is just a thin wrapper on top of C.
> Heck, you can just write C inline.
>
> Also, I do a good bit with Lua -- in httpd and other projects. Every time I
> run profiles on this stuff, Lua is always 3 out of the top 5 cpu consumers.
> And lots of it is just the language itself (all the table look-ups) and we
> highly optimized our method dispatches (using apr_hash, even had a version
> using gperf). Now this is probably just fine for mere mortals, but it has
> always bothered me. We always meant to go back and write higher level
> modules based on the "low level" Lua bindings, but we never did and we have
> several non programmers who are happily writing "configs" in Lua.
Are you using LuaJIT 2? The performance numbers its putting up seemed
very impressive.
http://luajit.org/luajit.html
Re: C as config
Posted by "Akins, Brian" <Br...@turner.com>.
On 6/8/10 6:34 PM, "Sean Conner" <se...@conman.org> wrote:
> If your platform is x86, have you considered testing with LuaJIT? It
> compiles Lua code directly into x86 code and is a drop-in replacement for
> lua (just link against libluajit instead of liblua). The few tests I've
> done have been impressive [1].
>From earlier in the thread:
On 6/4/10 7:30 PM, "Paul Querna" <pa...@querna.org> wrote:
> Are you using LuaJIT 2? The performance numbers its putting up seemed
> very impressive.
Yes and meh...
.....
The issue is, it still running Lua. Which, while fast compared to lots of
other languages is still much slower than C. Even when core httpd is doing
all the "heavy lifting" most of the CPU is spent doing Lua-stuff in our
case. And not even the interesting stuff...
--
Brian Akins
Re: C as config
Posted by Sean Conner <se...@conman.org>.
It was thus said that the Great Akins, Brian once stated:
> On 6/7/10 9:16 AM, "Dan Poirier" <po...@pobox.com> wrote:
> > Did you profile httpd? I'm wondering if you had a few non-trivial hooks
> > in lua, if it would be a significant part of the CPU consumption, or
> > would it be swamped by the rest of the processing that always goes on
> > for a request?
>
>
> Increasingly, httpd is just there to provide a base to run Lua stuff for us.
> You'd be surprised how easily problems get solved with a few if's and else's
> instead of mounds of rewrite rules.
>
> At "normal" load it doesn't really matter - the trade off is worth it
> ("speed" vs simplicity). However, as the servers get more and more loaded,
> Lua takes a rather large percentage of the CPU. And it's the "Lua stuff" not
> the part that does work. The constant string hashing, metatable lookups,
> etc.
If your platform is x86, have you considered testing with LuaJIT? It
compiles Lua code directly into x86 code and is a drop-in replacement for
lua (just link against libluajit instead of liblua). The few tests I've
done have been impressive [1].
-spc
[1] http://boston.conman.org/2010/02/03.2
Re: C as config
Posted by HyperHacker <hy...@gmail.com>.
On Tue, Jun 8, 2010 at 09:34, Akins, Brian <Br...@turner.com> wrote:
> On 6/8/10 8:07 AM, "Dan Poirier" <po...@pobox.com> wrote:
>
>> That's a shame. I wonder if another embedded language would do better?
>> E.g. mod_perl, mod_python? They've both been around for a while. I
>> wonder why neither has gotten into the server?
>
> Lua is leaps and bounds faster than both of those in my experience.
>
> --
> Brian Akins
>
>
Perhaps LuaJIT would make it faster still?
--
Sent from my toaster.
Re: C as config
Posted by "Akins, Brian" <Br...@turner.com>.
On 6/8/10 8:07 AM, "Dan Poirier" <po...@pobox.com> wrote:
> That's a shame. I wonder if another embedded language would do better?
> E.g. mod_perl, mod_python? They've both been around for a while. I
> wonder why neither has gotten into the server?
Lua is leaps and bounds faster than both of those in my experience.
--
Brian Akins
Re: C as config
Posted by Dan Poirier <po...@pobox.com>.
On 2010-06-07 at 17:42, "Akins, Brian" <Br...@turner.com> wrote:
> On 6/7/10 9:16 AM, "Dan Poirier" <po...@pobox.com> wrote:
>> Did you profile httpd? I'm wondering if you had a few non-trivial hooks
>> in lua, if it would be a significant part of the CPU consumption, or
>> would it be swamped by the rest of the processing that always goes on
>> for a request?
>
> Increasingly, httpd is just there to provide a base to run Lua stuff for us.
> You'd be surprised how easily problems get solved with a few if's and else's
> instead of mounds of rewrite rules.
Not really :-) I'm a huge fan of general-purpose scripting languages
whenever possible.
> At "normal" load it doesn't really matter - the trade off is worth it
> ("speed" vs simplicity). However, as the servers get more and more loaded,
> Lua takes a rather large percentage of the CPU. And it's the "Lua stuff" not
> the part that does work. The constant string hashing, metatable lookups,
> etc.
That's a shame. I wonder if another embedded language would do better?
E.g. mod_perl, mod_python? They've both been around for a while. I
wonder why neither has gotten into the server?
Dan
Re: C as config
Posted by "Akins, Brian" <Br...@turner.com>.
On 6/7/10 9:16 AM, "Dan Poirier" <po...@pobox.com> wrote:
> Did you profile httpd? I'm wondering if you had a few non-trivial hooks
> in lua, if it would be a significant part of the CPU consumption, or
> would it be swamped by the rest of the processing that always goes on
> for a request?
Increasingly, httpd is just there to provide a base to run Lua stuff for us.
You'd be surprised how easily problems get solved with a few if's and else's
instead of mounds of rewrite rules.
At "normal" load it doesn't really matter - the trade off is worth it
("speed" vs simplicity). However, as the servers get more and more loaded,
Lua takes a rather large percentage of the CPU. And it's the "Lua stuff" not
the part that does work. The constant string hashing, metatable lookups,
etc.
So, just as a test I converted a large amount of Lua into C. It was easy
enough and was a huge improvement.
So, just for Paul's benefit - we generate .so's from C ;)
--
Brian Akins
Re: C as config
Posted by Dan Poirier <po...@pobox.com>.
On 2010-06-04 at 18:21, "Akins, Brian" <Br...@turner.com> wrote:
> Also, I do a good bit with Lua -- in httpd and other projects. Every time I
> run profiles on this stuff, Lua is always 3 out of the top 5 cpu consumers.
> And lots of it is just the language itself (all the table look-ups) and we
> highly optimized our method dispatches (using apr_hash, even had a version
> using gperf). Now this is probably just fine for mere mortals, but it has
> always bothered me. We always meant to go back and write higher level
> modules based on the "low level" Lua bindings, but we never did and we have
> several non programmers who are happily writing "configs" in Lua.
Did you profile httpd? I'm wondering if you had a few non-trivial hooks
in lua, if it would be a significant part of the CPU consumption, or
would it be swamped by the rest of the processing that always goes on
for a request?
Re: C as config
Posted by Nick Kew <ni...@webthing.com>.
On 5 Jun 2010, at 03:18, Dennis J. wrote:
> The nginx syntax may look C-like but it really isn't at all. For one thing it's declarative and then you have all kinds of weird behaviors with variables and control structures that make no sense if you're coming from C-like angle.
>
> I think what Brian is really aiming for is an actual procedural configuration that basically gets executed when a request arrives. Something along the line of:
>
> function handleReq( req ) {
> if( req.domain ~ www.test.com ) {
> documentRoot("/sites/test");
> customLog("/var/log/test.log","combined");
> return true;
> }
> }
mod_perl springs to mind as offering that kind of thing since the year dot.
In trunk we have <If "..expr.."> for the above kind of construct. Should at least be
an improvement on hacking programmatic config with only single-IF and GOTO
as provided by mod_rewrite.
--
Nick Kew
Re: C as config
Posted by "Dennis J." <de...@conversis.de>.
On 06/05/2010 12:51 AM, Igor Galić wrote:
>> Not a terribly interesting read, but we are seriously considering just
>> using
>> straight C with some helper functions and macros as the "config" for
>> one of
>> our projects.
>>
>> And, for the record I was wrong in the past - yes, async is the
>> answer...
>
> I've been a longtime critic, though I haven't taken it to the list,
> of the httpd Configuration Language. For other reasons than performance
> though -- mostly sane defaults, but that's an entirely different topic.
>
> BUT: I did my share of support on nginx - even though I don't know it
> well enough and nginx, like varnish, uses a C-like syntax for the configs.
>
> I for one, would welcome such a possibility.
>
The nginx syntax may look C-like but it really isn't at all. For one thing
it's declarative and then you have all kinds of weird behaviors with
variables and control structures that make no sense if you're coming from
C-like angle.
I think what Brian is really aiming for is an actual procedural
configuration that basically gets executed when a request arrives.
Something along the line of:
function handleReq( req ) {
if( req.domain ~ www.test.com ) {
documentRoot("/sites/test");
customLog("/var/log/test.log","combined");
return true;
}
}
Not sure if that would do much for Apache but with nginx sometimes I really
would like to have something like this.
Regards,
Dennis
Re: C as config
Posted by Igor Galić <i....@brainsware.org>.
> All of you folks who have to answer user questions, go ahead and ready
> your
> hate mail :)
This is not a hate-mail (:
> I've been playing some with Varnish (long story) and lots of people
> seem to
> like it. The config "language" (VCL) is just a thin wrapper on top of
> C.
> Heck, you can just write C inline.
I know and love varnish. And sadly, the only reason I don't use it right now,
is because it's oblivious of SSL.
> So, we thought about "wouldn't it just be cool if Apache had VCL."
> Then I
> thought, I already know C, why do I need to learn a meta-language that
> just
> writes C??? "Won't someone think of the users!" I could here all of
> the
> #httpd folks saying.
>
> Not a terribly interesting read, but we are seriously considering just
> using
> straight C with some helper functions and macros as the "config" for
> one of
> our projects.
>
> And, for the record I was wrong in the past - yes, async is the
> answer...
I've been a longtime critic, though I haven't taken it to the list,
of the httpd Configuration Language. For other reasons than performance
though -- mostly sane defaults, but that's an entirely different topic.
BUT: I did my share of support on nginx - even though I don't know it
well enough and nginx, like varnish, uses a C-like syntax for the configs.
I for one, would welcome such a possibility.
--
Igor Galić
Tel: +43 (0) 699 122 96 338
Fax: +43(0) 1 91 333 41
Mail: i.galic@brainsware.org
URL: http://brainsware.org/