Date: Fri, 29 Jan 1999 14:21:26 -0800 (PST)
From: Dean Gaudet <dgaudet@arctic.org>
To: new-httpd@apache.org
Subject: Re: Thread/Process model discussion.
In-Reply-To: 
 <Pine.A41.4.05.9901291005440.16738-100000@webdev7.raleigh.ibm.com>
Message-ID: <Pine.LNX.3.96dg4.990129140948.22674M-100000@twinlark.arctic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

On Fri, 29 Jan 1999, Ryan Bloom wrote:

> > 	Logging.  Do we want a logging thread?  What benefits does it give
> > us?  Drawbacks?
> 
> Okay, I will now suggest a possible solution.
> 
> Each process has it's own low priority logging thread, which grabs the
> logging data  from a queue.

i.e. you're re-inventing append only files. 

> writting logs.  This could cause the queue to fill, and then all the
> threads are wasted, because they can't put their logging information
> anywhere.

Yeah that's a terrible situation, which only exists in the model you
propose. 

> The logging queue wakes up every few seconds (or once a second,
> preformance tests could tell us how often is required), and writes a burst
> of messages to the log file.  When the thread wakes up, it creates a new
> queue, and replaces the old queue with the new one.  This allows the other
> threads to continue as if nothing has changed.  It then dumps the log
> messages to the appropriate log file.

If your server is so busy that logging is a CPU issue for you, then I
suggest: 

- you use unix where append only files have sane semantics
- you use BUFFERED_LOGS (see mod_log_config.c)
- you sort your logs offline, on a CPU/disk that's not in your web farm

> The advantage to this, is that the disk I/O is going to be a killer, and I
> don't think we want multiple threads blocking on disk I/O.

Why not? 

That's the best possible thing an application can do: give the kernel all
the information it needs to optimize a solution.  Multiple threads blocked
in an append-only write on a file can be ordered in any damn way the
kernel pleases (as long as it maintains the atomicity of each individual
write).  And if they're all blocked, then clearly there's a lot of data to
be logged -- you have to pay for it somewhere.

> There were two messages about rotating logs, and I think this solution
> also provides us a nice way to rotate logs.

There is already a nice way to rotate logs.  Study how the pipe() is used
in apache.  Notice that it provides a seamless way to rotate logs, and has
absolutely no problems in a multiprocess or multithreaded environment. 

Too bad it only works on unix. 

How's that quote go?  "those who don't understand unix are doomed to
re-invent it"  ? 

:) 

OK, since you have to re-invent unix I suggest you do not have a dedicated
logging thread.  Instead I suggest that, since you already need to
synchronize your threads to add log entries to the queue, have the thread
which notices the queue is full flush it to disk... it's already in the
critical section when it notices, and so you save yourself two context
switches.  This simplifies the implementation... and in fact is somewhat
better than what unix can give.  But we're down in the 1 or 2% range I'm
guessing. 

I still believe log rotation, along with log splitting for massive numbers
of vhosts, belongs outside httpd.  Search the archives for the many
previous discussions of this.  KISS. 

Dean