[hunchentoot-devel] Hunchentoot performance

vseguip at gmail.com vseguip at gmail.com
Sat Dec 22 17:03:00 UTC 2007


Hi Edi,
 Thanks for your quick reply.

> Thanks for the code and the benchmarks, but currently I have no plans
> to integrate something like this into Hunchentoot.


That was not my intention (I would have sent it as a patch using your
coding conventions) and it wouldn't make any sense either since it
doesn't need to be integrated in Hunchentoot.

>
> But, more importantly, the "philosophical" reason:
>
> Do you have a real-world application that you'd like to use
> Hunchentoot for where you actually expect more than 250 requests per
> second?  If so, it seems that you have a very successful business and
> I'd be happy to sign a support contract with you and add whatever
> feature you want to Hunchentoot.  If not, I'd rather concentrate on
> bugfixes, interesting new features, and ease of use.

Well if I had a successful business requiring that load I would just
go along with lighttpd for static files :). My intention is just to
learn Lisp, and when I try to learn any language I try to read
existing code bases and try to see if I can hack them to do something,
be it improving performance, adding features etc.  I think I didn't
express my intentions well in my opening post so it's really my fault.
So I will try to make more concrete questions: why are functions like
get-request-data or write-header-line more time consuming the sending
the whole file (even when not using "sendfile")? I was trying to seek
an explanation for that since I doesn't seem to make much sense from
just reading the code, and maybe, just maybe, try to improve
performance (I am guessig that those functions are also being called
in dynamic requests so it could help there too) as a learning
exercise.

Cheers,
 V. Seguí

@Bob: thanks a lot for your hints, but I was just doing this as an
educational exercise in my quest to learn Common Lisp. I do however
keep in mind that information in case I ever have the need for it.



More information about the Tbnl-devel mailing list