[hunchentoot-devel] Hunchentoot performance

[Edi Weitz]

On Sun, 30 Dec 2007 18:55:22 +0100, vseguip at gmail.com wrote:

> Anyway, is there a more elegant way to turn logging off than simply
> redefining the method?

Sure.  There are several ways to control this:

  http://weitz.de/hunchentoot/#log

You could for example turn access log messages off.  Of course, once
you have your 300-visitors-per-second website, you probably /want/
logging... :)

> I think the fact that log-message is locking when logging to a file
> makes it take a sever performance hit, maybe the use of a logging
> framework that solves this would be nice.

Yes, maybe.  Is there a mature, stable, well-documented logging
framework out there that works with all Lisps supported by
Hunchentoot?  How would such a framework deal with several threads
trying to log at the same time if not with locking?

One could also think of a setup where there's one dedicated logging
process and other processes write to the log file by sending objects
to its mailbox:

  http://cl-cookbook.sourceforge.net/process.html#mailbox

(Or use cl-muproc?  Maybe a bit of overkill.)

But that would cancel the support for non-threaded Lisps we have now
and it would introduce more implementation-dependent code.

Anyway - not a big priority for me.  If it's important for you, I'd
suggest you make a detailed proposal, we discuss it here, then you
send a clean patch.

> On a side note, I wanted to comment some refactoring to hunchentoot
> that I think may make sense. Right now process-connection is a
> function that takes care of reading from the client, be it via
> mod_lisp or directly, binding the chunga/flexi-streams if needed and
> dispatching it. I think a better design would be to make
> process-connection a generic method on class connection and then
> implementing methods for
> mod_lisp/standalone/fastcgi/whatever. Chunga and flexi-streams
> wrapping could be implemented as mixins so the user can choose to
> create a FCGI connection with flexi but not chunga, etc.  With this
> we can allow for custom backends to be developed by users so we gain
> flexibility (and maintainability) at the cost of some overhead when
> dispatching. What do you think?

I'm always open for changes which improve flexibility and
maintainability and at first sight your proposal sounds fine to me.
If you want to implement that, I'd suggest to proceed like I described
above.

Edi.