[hunchentoot-devel] 'max-threads' behavior for Hunchentoot

[Scott McKay]

Hans, I've attached a file with the diffs against
(what I believe is) the latest version of Hunchentoot.
This does what we discussed.


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: htoot-diffs.text
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100607/97382f97/attachment.text>
-------------- next part --------------



On Jun 5, 2010, at 9:29 AM, Hans H?bner wrote:

> On Sat, Jun 5, 2010 at 15:01, Scott McKay <swm at itasoftware.com> wrote:
>> Right now, the default for 'one-thread-per-request-taskmaster'
>> (or whatever it's called) is what it used to be: just keep
>> accepting connections.  If you'd like me to change that to
>> "accept N connections and spin off a thread; queue up a few
>> more connections; then issue HTTP 503", that would suit me
>> just fine.  It seems like a good, default behavior.  The one
>> question I have is, what should N be and what should the
>> increment be beyond which we reject?  I'm thinking something
>> like allow 8 threads, and 2-4 on the queue, but I'll go with
>> whatever you think is reasonable.
> 
> The default limit for threads needs to be much larger than 8 as -
> correct me if I'm wrong - there is one thread per connection, not per
> request.   This means that the number of threads allowed is basically
> identical to the number of simultaneous clients.  Lets set the default
> limit to 100 so that Hunchentoot is not the first thing one needs to
> tune when coping with larger loads.  The listener queue length should
> not be too short (something like 30-50) so that load transients can be
> handled.
> 
> Enjoy your weekend,
> Hans
> 
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel