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

[Hans Hübner]

Scott,

thank you for the patch.  May I ask you to add a documentation update?

Thanks,
Hans

On Mon, Jun 7, 2010 at 21:14, Scott McKay <swm at itasoftware.com> wrote:
> Hans, I've attached a file with the diffs against
> (what I believe is) the latest version of Hunchentoot.
> This does what we discussed.
>
>
>
>
>
>
> 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
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>